12 tricks to improve EJB performance

Enterprise JavaBeans (EJB) is a widely used service-side component architecture based on the Java EE platform, which can be used to quickly develop flexible, reusable, mission-critical enterprise applications that can be ported to various middleware platforms. At the same time, the EJB architecture protects it investments, reduces dependence on vendors, and avoids limitations on the technology implementation of a single vendor, due to the adoption of open collaboration specifications. Among them, performance is the key to the success of an EJB application.

To develop high-performance enterprise applications, we must be aware that good design and programming specifications are the basis for performance improvement. The ideal state is that before we develop, we must first master the excellent programming specifications. Later in development, the focus shifted to the overall application performance tuning: including Web servers, application server industries, and databases. The strategy is to identify a vulnerable link and then make improvements. For best performance, this article discusses some common techniques that will help us design and implement a high-performance EJB-based enterprise application.

The development of EJB

Our top eight EJB performance techniques are related to the design and development phases of the application system. Because in a server environment, most code that needs to be optimized is more in front of the layout phase. To find out and solve problems before they get out of hand.

1. Design coarse granularity (coarse-grained) EJB remote interface

Because each method that invokes an EJB through a remote or local (home) interface is a remote invocation, the overhead of invoking the middleware for most fine-grained (fine-grained) object interactions is overwhelming. To avoid this type of problem, each EJB should represent a separate business object with independent features and lifecycle. Objects that have dependencies must never be represented by EJBS. Instead, it should be implemented as a Java class within the EJB. For example, a shopping list can be implemented using an EJB, and the subkeys on each shopping list should not be EJB-enabled and implemented in the form of helper classes.

2. Design coarse granularity EJB Remote interface method

As mentioned above, each client's invocation of the EJB is a remote call, and some checks are performed, such as access control, transaction processing, activation/hibernation, and so on. Therefore, the EJB call is a few times slower than a remote call, and the time difference between invoking the local method is greater. Reducing the number of calls to a method can improve performance. One technique in designing a rough line optimization is to maximize the number of data transmitted back and forth during a single method invocation and combine multiple methods to reduce the number of methods. For example, the code snippet shows a poorly designed remote interface because the client must call it multiple times to get the person's data. In contrast, code segment two improves performance because it uses coarse-grained methods in one method invocation and fewer methods, reducing the number of calls (although these methods transmit more data).

3. Reduce the number of Jndi lookups

The JNDI lookup process can be time-consuming due to differences in the way the naming and directory services for various application servers are implemented. (Note: Jndi lookups of EJB resources, such as data sources, bean references, and even environment items (environment entry) can be costly, and avoiding duplicate lookups is not easy.) Some application servers use separate processes on different machines to implement directory information. Caching the home handle in this case is a good way to improve performance. (See Code Snippet 3). A façade is an object that provides a unified interface for multiple objects. A façade on a service side simplifies processing so that the client does not need to know each server-side EJB (see figure I). In this way all client calls to the server are Serverfacade through the object. As shown in code Snippet 3, Serverfacade is a session EJB that caches the home handle of all required EJBs. Customers can also cache Serverfacade home handle with singleton objects on the client.

Figure 1. The client accesses the server through Serverfacade. Serverfacade is a session EJB that caches the home handle of all needed ejbs.

4. Return multiple rows of data from one entity bean using a packet from a session bean

Typically, a bean in our application represents a logical row of the database. One or more finder methods are defined in the local interface of the entity bean. Each method is used to find a collection of entity objects or multiple entity objects. A collection of entity objects is obtained at the client by invoking the Finder method of the entity bean. The client then obtains the data sequentially from the collection. If it is a remote client, the resource overhead is too high for one row of data to be obtained each time a long procedure call. We can use a session bean at the server side to package all the rows as a result of the Finder method of an entity local object. Code Snippet 4 shows how a session bean object sends a vector/collection of multiple rows of data to the client through one call. This method can be used when a GUI data, such as a list box or spreadsheet, remains static. The extension of this approach can also support the client's data modification.

5. Use session beans to handle a large number of database operations

Entity beans are designed to work on one logical row of a database at a time, but there is a lot of performance overhead in the bulk operation of the database. For example, a Finder method that returns an entity bean of 1000 rows needs to perform a select operation of 1001 databases, resulting in a sharp drop in performance. If you use a session bean to handle the bulk operation of a database, you can significantly improve performance (see Code Snippet 5) because it reduces the number of calls to the database.

6. Use CMP (container-managed persistence) container management beans as much as possible instead of BMP (bean-managed persistence Bean)

In BMP, the person writing the bean must own the database access code in the Bean's method using JDBC,SQLJ, and so on. In CMP mode, the container in the EJB deployment is the automatic generation of database access code. The person who writes the bean simply specifies in the deployment descriptor the field manifest of the instance that will automatically generate the access code. The advantage of CMP is that it enables the Bean class to be independent of the data source. Another benefit is that the application server's manufacturers generate optimized code for CMP to improve database access performance.

7. Proper use of entity beans

It is appropriate to use entity beans for certain situations. They apply to fetching only a small number of rows of data from a database for simultaneous access by multiple users. For example, in person, when the individual logs on to the system, his records can be cached and have multiple EJB accesses, such as Securitybean, Bankaccountbean, and so on. So person can exist as entity bean. Entity beans also apply to situations where data rows need to be updated frequently in multiple transactions.

Due to performance overhead, entity beans are not appropriate for a large number of data rows to be selected, inserted, or updated in database processing. In this case, you might consider using session beans, and you can also design rough-optimized database access operations in entity beans.

8. Adoption of appropriate isolation levels

The isolation hierarchy is the degree to which multiple alternating transactions avoid interference between each other. Transaction_serializable is the highest isolation level. Adopting this isolation level makes the entire process rather slow, because all transactions (both simple read operations) must be queued up to execute sequentially. The method that is executed obtains a lock on the exclusive write data, preventing other transactions from reading, updating, or inserting the data until the transaction completes successfully and submits the work. At the transaction_repeatable_read level, transactions cannot modify data that is being read by other transactions. Write locks are used to prevent other transactions from modifying the data. When the transaction_read_commited level is adopted, the current transaction cannot manipulate the intermediate state of the data by other transactions. Because it cannot add write locks to data that is being modified by other transactions, it is not possible to read half of the data modified. Transaction_read_uncom-mited is the lowest isolation level. In this level, the bean's methods can read the intermediate state of the operational data, but they are not aware of the addition of new records.

The higher the isolation level, the greater the overhead. Typically, a lower isolation level allows for more concurrent operations, at the cost of requiring more complex logic to deal with potential data inconsistencies. A useful guideline is to use the highest possible isolation level within the acceptable performance range of the enterprise information System.