Enterprise JavaBeans
Enterprise JavaBeans (EJBs) are an important aspect of the J2EE specification, and appropriate use of EJBs can support the development of modular and scalable applications. There are, however, a number of performance considerations that need to be taken into account when using EJBs:
Obtaining EJB references Since EJBs are able to be accessed remotely, obtaining a reference to an EJB involves a lookup process. This can take a relatively long time, and hence caching the references obtained can improve performance on subsequent lookup operations. Obtaining an EJB reference typically involves the following steps:
a. Obtain an InitialContext instance. b. Obtain a reference to the home interface of a particular EJB by looking up the EJB via the initial context object and performing a narrow operation. c. Obtain a particular EJB instance by executing the appropriate finder or create method from the EJB home instance. The calls to obtain an InitialContext instance and lookup of an EJB Home instance (steps a and b) are expensive, and performance can be improved by caching these objects. References to EJB homes may become stale, and hence it is best to wrap accesses to EJB Home methods with code that refreshes stale references.
Remote method calls Since EJBs are intended to be accessible remotely, calls to EJB methods are implemented as remote calls even if the EJB exists in a container that shares the same JVM as the Web container, which introduces some overhead. In some cases, the overhead can be reduced by implementing approaches outlined below.
One of the key mechanisms to reduce EJB overhead is to minimize the number of remote calls. In general, a servlet should make a single EJB method call to a session bean to perform an operation. If required, this EJB method can call other methods as required to perform more complex operations. All access to Entity EJBs should be performed through stateless session beans. Session beans should be used to implement the business logic, while entity beans should be used for data storage and retrieval.
IBM WAS V5.1 is compliant with the J2EE 1.3 specifications, which mandate support for EJB 2.0. The concept of a local interface has been introduced for EJB 2.0. If local interfaces are used, the overhead of serializing the parameters and transmitting them via RMI/IIOP (Remote Method Invocation/Internet Inter-ORB Protocol) is avoided. Parameters can be passed by reference instead of value, avoiding the need to copy them. In EJB 2.0, an EJB can have a remote interface, local interface or both, although typically a particular bean will have either a remote or a local interface. Since Entity EJBs are normally accessed from session beans, in most cases they will only need local interfaces.
Transaction management In addition to the overhead associated with remote method calls, transaction management provided by the EJB container can also introduce overhead. Accessing entity beans from session beans can limit the impact of this by reducing the number of transactions. In the deployment descriptor for EJBs, the transaction type can be specified. This can be one of five values: NotSupported, Supports, Required, Requires New and Mandatory. Set the transaction type to NotSupported if no transaction is required.
Entity EJBs While entity beans can reduce the amount of coding work required by freeing programmers from having to write code for persisting data, care must be taken with the use of entity beans to avoid performance problems. As mentioned earlier, it is recommended that entity beans are only accessed from session beans and not directly by servlets or other clients. The EJB access beans functionality provided in IBM WebSphere Studio Application Developer V5.1.1 can also be used to simplify access to EJBs.
In cases where entity beans have deep relationships or significant use of inheritance, care must be taken to ensure that performance is adequate. If performance problems are encountered, they can potentially be addressed by reducing the use of inheritance in the model or by use of bean-managed persistence (BMP) in preference to container-managed persistence (CMP). Another strategy is to avoid turning each entity (table) into a single EJB - in some cases two or more related entities can be represented by a single EJB.
Entity EJBs are best used for manipulating small amounts of data. Returning large result sets from (default) EJB finders can be inefficient and it is often better to use JDBC directly from a session bean for this.
Important: The following applies only to EJBs that are compliant with the EJB 1.1 specification. We recommend that new EJBs be developed to be compliant with the EJB 2.0 specification. However, some existing EJBs may only be compliant with EJB 1.1.
Isolation levels and read-only methods If an entity bean has methods that do not update attributes (getter type methods) they can be specified as read-only methods in the deployment description. This will avoid executing a SELECT for UPDATE/UPDATE pair of SQL statements, and hence will provide a performance improvement.
EJBs deployed in WAS can be assigned one of four transaction isolation levels. These are Repeatable Read, Read Committed, Read Uncommitted and Serializable. The default level is Repeatable Read, but performance can be improved by the use of a lower isolation level such as Read Committed.
Important: The following applies only to EJBs that are compliant with the EJB 2.0 specification.
Access intent The access intent for each method of an EJB 2.0 CMP entity bean can be specified in the EJB deployment descriptor to provide hints to the EJB container about how the method will be used. The supported access intents are pessimistic update - Weakest Lock At Load, pessimistic update, optimistic update, pessimistic read, and optimistic read. In general, read-only methods and optimistic locking will provide better performance. However, be careful with the use of optimistic locking since problems may only become apparent under heavy load and hence may not be found in development.
Stateful session beans The use of stateful session beans should be minimized (or avoided if possible). Unlike stateless session beans, they are not able to be work load managed or pooled. The EJB container may passivate inactive stateful session beans and activate them if they are referenced later. This involves serializing and deserializing the beans, which can impact the performance. In cases where stateful session beans are required, the occurrence of passivating the beans can be reduced by explicitly removing the beans when they are no longer required, rather than waiting for them to time out.
One scenario in which stateful session beans may be useful is the implementation of a cache for application data. This may use JDBC or a BMP entity bean to retrieve the data to be cached.
EJB caching The EJB container has three types of caching that can be performed for entity beans between transactions. Selection of the appropriate option requires an understanding of how the entity beans will be used, as there is a trade-off between minimizing database reads and supporting Workload Management (WLM).
Option A caching With this option, it is assumed that the data represented by the EJB is exclusively accessed by the EJB container and is not accessed by other containers or by some mechanism that is external to the appserver. Use of this option can improve performance, since the data does not have to be retrieved again from the database prior to each transaction. However if option A caching is used, the entity bean cannot be clustered or participate in WLM.
Option B caching The entity bean will remain in the cache throughout the transaction, but is reloaded at the start of each method call. This introduces the greatest overhead.
Option C caching The entity bean will be reloaded at the beginning of each transaction. This is the default setting, and allows for a client to access a particular bean from any container.
Asychronous message processing Asychronous JMS messages can be processed using message-driven beans (MDBs), which have been introduced in WAS V5.0. This avoids the need for developing individual server programs to receive and process incoming messages.
Prev | Home | Next WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.