Scaling EJB Applications

 

This topic describes the EJB application scaling tasks associated with the EJB architecture roles specified in Chapter 3 of the Enterprise JavaBeans Specification 1.1, publish by Sun Microsystems, Inc. The WebLogic Enterprise JavaServer provides an implementation of the EJB container as defined in this specification.

This topic includes the following sections:

• Scaling Tasks for EJB Providers

• Scaling Tasks for Application Assemblers and Deployers

• Scaling Tasks for System Administrators

Before you begin, be sure to read Scaling WebLogic Enterprise Applications, for a comprehensive introduction to tuning and scaling WebLogic Enterprise applications. The concepts in that chapter apply to EJB applications as well. The main difference is that factory-based routing is not supported in EJB applications.

In addition, for an introduction to using EJB applications in the WebLogic Enterprise environment, see "Developing WebLogic Enterprise EJB Applications" in Getting Started.

 

---

Scaling Tasks for EJB Providers

This topic includes the following sections:

• Using Stateless Session Beans

• Minimizing State Information in Stateful Session Beans

• Using Pooled Connections

• Implementing Methods for Bean Persistence

• Completing Transactions Efficiently

• Implementing the Process-entity Design Pattern

For a general discussion about using stateful and stateless objects, see Using Object State Management.

Using Stateless Session Beans

EJB Providers can increase application scalability by using stateless session beans wherever appropriate. With stateless session beans, the WebLogic Enterprise EJB container can freely pool instances, allocate instances as needed, and apply load balancing strategies to distribute the load across different servers within the domain.

Stateless session beans can be load balanced on a per-request basis. With every method invocation, a stateless session bean can be relocated to the least busy server within a group or across groups within a domain. For more information about stateless session beans, see "Types of Beans Supported in WebLogic Enterprise" in "The WebLogic Enterprise JavaBeans Programming Environment" topic in Getting Started.

Although stateless session beans by definition do not have a persistent state for client applications, they can have instance variables that retain values while the EJB remains in an instance pool on the server. This WebLogic Enterprise feature allows EJB Providers to implement highly scalable EJBs. For example, suppose a stateless session bean invokes methods on a CORBA object. Normally, for each method invocation, the EJB needs to make two calls: one to obtain an object reference, and another to invoke the method. However, the EJB can store the object reference in an instance variable. Thereafter, when an application invokes a method on the EJB, it can be retrieved from the pool if it is available in the pool. The application can then check the instance variable for a valid value; if it is valid, the application can avoid making an extra call to obtain the object reference.

Minimizing State Information in Stateful Session Beans

EJB Providers can increase application scalability by minimizing, in stateful session beans, the state information that must be stored and retrieved during passivation and reactivation.

Stateful objects (stateful session beans and entity beans) are generally more resource intensive than stateless objects because they allocate and exclusively reserve resources during the private conversation with the client. After the state is allocated for an object, the object remains linked to that server for the duration of the method invocation or the transaction. Stateful session beans can be load balanced using any server that supports the bean within the group only (not across groups).

Using Pooled Connections

EJB Providers can increase application scalability by using pooled database connections. The JDBC connection pool optimizes performance for database connections by reducing the overhead associated with opening each connection. For more information about configuring and using JDBC connection pools, see Using JDBC Connection Pooling.

Implementing Methods for Bean Persistence

To optimize application performance, the WebLogic Enterprise EJB container manages the passivation and reactivation of stateful objects (stateful session beans and entity beans) automatically, based on available system resources. The container can pool instances of a bean and decide when an instance can be removed from the pool to provide a more efficient use of system resources. The WebLogic Enterprise EJB container may passivate an object after a method invocation.

Note: An object will not be passivated while it participates in a transaction. The WebLogic Enterprise EJB container may passivate it only after the transaction is completed.

The WebLogic Enterprise EJB container manages load balancing with passivated objects. After it is passivated, the WebLogic Enterprise EJB container can relocate an object to the least busy server within the group as long as the object is idle (there are no pending requests on that object). This is particularly important when the bean accesses a database using cursors, because these cursors could become invalid after the passivation (the EJB container can reactivate the bean on a different server).

For stateful session beans and entity beans, EJB Providers can increase application scalability by implementing the ejbPassivate and ejbActivate methods in an efficient manner. For more information about persistence in EJB applications, see "EJBs and Persistence" in "The WebLogic Enterprise JavaBeans Programming Environment" topic in Getting Started.

Finally, for stateful session beans with container-managed persistence, EJB Providers should favor using JDBC-based persistence over file-based persistence. File-based persistence is generally less scalable. If the client process crashes (for example, the network connection is lost or the client machine is turned off), the file is not automatically removed. An accumulation of these files can slow performance.

Completing Transactions Efficiently

EJB Providers can increase application scalability by completing transactions efficiently. An object cannot be passivated while it is participating in a transaction. For example, EJB Providers can specify the timeout period for transactions in EJB applications. If the duration of a transaction exceeds the specified timeout setting, then the Transaction Service rolls back the transaction automatically. For more information, see "Transactions in EJB Applications" in Using Transactions.

Implementing the Process-entity Design Pattern

EJB Providers can increase application scalability by using the process-entity design pattern instead of entity beans for database access. The process-entity design pattern moves database access logic onto the server process, which achieves the following benefits:

• It reduces the server load, as the server no longer needs to manage thousands (even millions) of entity beans, each requiring transaction overhead.

• It minimizes network traffic between client applications and servers.

For more information, see the technical article Process-Entity Design Pattern.

 

---

Scaling Tasks for Application Assemblers and Deployers

This topic includes the following sections:

• Organizing EJBs in Groups

• Configuring the Persistent Storage Location

• Specifying the Method to Invoke Before Passivation

• Deploying Stateful Session Beans on the IIOP Listener Node

• Configuring the EJB Cache

Application Assemblers and Deployers contribute to the scalability of EJB applications by determining the optimum combinations of EJBs in an application's EJB JAR files. When partitioning EJBs, Application Assemblers and Deployers should consider the topology and resource management capabilities provided by the deployment environment. Deployers and system administrators usually collaborate on such decisions.

Organizing EJBs in Groups

When deploying EJBs, consider organizing them in particular groups:

• Wherever possible, objects that call each other should be in the same group.

• EJBs that access the same resource manager should be placed on the same group and might be packaged together in a single EJB JAR file.

Configuring the Persistent Storage Location

Stateful session beans use file-based persistent storage. For stateful session beans, the WebLogic Enterprise EJB container creates a pstore subdirectory in the $APPDIR directory to store the state information when stateful bean are passivated. When deploying WebLogic Enterprise applications, you should locate the pstore directory in a local file system and not on a NFS mounted directory.

You can change the location of the pstore directory by specifying the <persistence-store-directory-root> element in the weblogic-ejb-extensions.xml file, as shown in Listing 4-1.

Listing 4-1 Configuring for Persistent Storage

---

<persistence-store-descriptor>
      <persistence-store-file>
      <persistence-store-directory-root>         /usr/me/pstore</persistence-store-directory-root>
       </persistence-store-file>
   </persistence-store-descriptor>

---

For more information about the weblogic-ejb-extensions.xml file, see the WebLogic Enterprise EJB XML Reference. You can also change this setting with the WebLogic Enterprise EJB Deployer, as described in Using the WebLogic Enterprise EJB Deployer.

Specifying the Method to Invoke Before Passivation

If a stateful bean is involved in a transaction, the container loads and stores the bean at appropriate times during the transaction, but does not activate or passivate the bean. If a stateful bean is not involved in a transaction, the methods ejbLoad and ejbStore are called before and after each method invocation on the bean. As stated in the Enterprise JavaBeans Specification 1.1, these load and store operations ensure that stale data is not used.

For stateful EJBs, you can specify the EJB method that is called before the EJB is stored by setting the is-modified-method-name element in the weblogic-ejb-extensions.xml file. The is-modified-method-name element points to the method that is called before the EJB is stored. For more information about the weblogic-ejb-extensions.xml file, see the WebLogic Enterprise EJB XML Reference. You can also change this setting with the WebLogic Enterprise EJB Deployer, as described in Using the WebLogic Enterprise EJB Deployer.

Deploying Stateful Session Beans on the IIOP Listener Node

Stateful session beans are conversational and therefore many messages could go to the same bean. To reduce traffic across machines, deploy stateful session beans on the node on which the IIOP Listener (ISL) runs. Clients access the WebLogic Enterprise EJB container by establishing a network connection and using the RMI on IIOP protocol to invoke EJBs. The ISL load balances incoming client connections. For more information about ISL, see Multiplexing Incoming Client Connections.

Configuring the EJB Cache

If an application encounters the weblogic.ejb.internal.CacheFullException exception for stateful beans, try to change the capacity of the cache or turn caching off. This exception is thrown when the WebLogic Enterprise EJB container does not find any beans that can be flushed (that is, beans in cache are either in a transaction or in a method invocation). This exception is never raised if caching is off. This exception is logged in the ULOG and a RemoteException exception, with a nested org.omg.CORBA.INTERNAL exception, is returned to the client. Any client transaction involved in the request receiving the system exception CacheFullException will be rolled back.

EJB caching is enabled by default. Disable EJB caching for individual beans only when necessary. You can disable caching for an individual bean by setting the is-cacheable element in the weblogic-ejb-extensions.xml file. For more information about the weblogic-ejb-extensions.xml file, see the WebLogic Enterprise EJB XML Reference. You can also change this setting with the WebLogic Enterprise EJB Deployer, as described in Using the WebLogic Enterprise EJB Deployer.

 

---

Scaling Tasks for System Administrators

System administrators contribute to the scalability of EJB applications by configuring and tuning the deployment environment for optimum application performance. System Administrators can increase application performance by:

• Replicating servers and server groups, as described in Replicating Server Processes and Server Groups.

• Using multithreaded Java servers, as described in Using Multithreaded Java Servers (Java only). In general, EJB applications perform better when running on multithreaded Java servers.

• Supporting additional incoming client connections, as described in Multiplexing Incoming Client Connections.

• Removing Orphan Files for File-based Persistence, as described later in this section.

• Scaling and Tuning the EJB Cache, as described later in this section.

Removing Orphan Files for File-based Persistence

System administrators should periodically remove orphan files associated with stateful session beans that use file-based persistence.

With file-based persistence, WebLogic Enterprise stores the bean's state in a file in a directory, which is either the pstore subdirectory in the $APPDIR directory, or the directory specified by the setting of the persistence-store-directory-root XML element in the weblogic-ejb-extensions.xml file. If the client process crashes (for example, the network connection is lost or the client machine is turned off), the file is not automatically removed. An accumulation of these files can slow performance.

System Administrators can create startup scripts that delete these files whenever the WebLogic Enterprise environment is shut down and restarted. For more information, see "Starting and Shutting Down Applications" in the Administration Guide. For more information about monitoring and tuning the performance of a WebLogic Enterprise system, see "Monitoring a Running System" in the Administration Guide. For more information about the weblogic-ejb-extensions.xml file, see the WebLogic Enterprise EJB XML Reference.

Scaling and Tuning the EJB Cache

System administrators can scale and tune EJB applications by using the WebLogic Enterprise caching features for entity beans and stateful session beans. The WebLogic Enterprise EJB container supports caching beans across method invocations as well as across transactions. This capability improves performance by significantly reducing the frequency of beans being passivated. EJB caching is enabled by default for stateful beans.

A cached stateful bean is normally stored (passivated) only if it is unused for a period of time. You can configure an optional cache flush time, if desired. A bean may be considered unused if other beans are being used more frequently and the bean is the least recently used bean. The bean may also be passivated if the cache flush time occurs and the bean is not presently active within a method call or a transaction.

Mechanisms For Managing the WebLogic Enterprise EJB Cache

EJB caching is enabled by default for stateful session beans and entity beans in the EJB container. You can set up caching using the following mechanisms:

• Via the WebLogic EJB extensions to the deployment descriptor DTD. You can use the is-cacheable element to disable caching for individual beans. For more information, see Configuring the EJB Cache.

• Via JavaServer parameters in the UBBCONFIG file. You can configure the following two settings for bean caching:

  • MAXEJBCACHE is the maximum number of beans that can be cached at any one time.

  • EJBCACHE_FLUSH is the number of minutes between cache flushes, when the bean cache is to be flushed by the system. You can specify the number of minutes between cache flushes. At the interval specified by the cache flush time, all beans that are not currently in a transaction or a method invocation are passivated and their memory is freed.

    For more information about these parameters, see "Creating a Configuration File" in the Administration Guide.

Tuning the Cache

Sizing the bean cache correctly is very important. If you are using multithreaded servers, the cache should at least be the number of threads in the server. If the cache is smaller than the number of threads, applications could encounter the CacheFullException exception because all the beans (one per thread) are active in a method invocation.

The optimum number of beans to maintain in the cache should be based on how many beans can be active simultaneously in the server process. This number is determined by:

• How long a bean will remain active in a server before it can be removed or is dormant.

• How many threads the server has.

Note the following regarding tuning and scaling the bean cache:

• While a bean is cached in a server process, all requests for the bean return to the server process that has cached the bean. Caching a bean effectively disables load balancing for the bean. The advantage of caching a bean is that caching saves a lot of activation and passivation, which involves persistent storage I/O and uses Java File Serialization to store conversational state.

  Every bean is passivated immediately after creation to give an opportunity to balance the load. This approach incurs at least two I/O cycles during the lifecycle of a stateful bean, even though the lifecycle may be relatively short. This could change in the future based on customer input regarding the pattern in which stateful beans are used.

  In general, BEA recommends not flushing the cache frequently. However, after a cache flush, all the beans not then active (in a method or a transaction) are again available for load balancing to servers supporting the bean.

• If a server process in which a cached bean exists crashes, there is no recovery of that bean's state.

• Every bean cache entry potentially uses an Active Object Map (AOM) entry. The default 1,000 objects in the AOM parameter specified in the UBBCONFIG file may be insufficient if you have many server processes with many large caches.