Transaction Commit Options

Transcription

1 Transaction Commit Options Entity beans in the EJB container of Borland Enterprise Server by Jonathan Weedon, Architect: Borland VisiBroker and Borland AppServer, and Krishnan Subramanian, Enterprise Consultant Borland Software Corporation June 2002 Introduction This paper provides an overview of the transaction commit options defined in the Enterprise JavaBeans (EJB ) specification and how the EJB container in Borland Enterprise Server, AppServer Edition handles those options. The various transaction commit options defined in the EJB specification are applicable to entity beans only. This paper enumerates the behavior and performance of entity beans running within the EJB container of Borland Enterprise Server when using each of the transaction commit options. Entity beans reviewed Entity beans provide an object view of data. The data is usually stored in a relational database, although it is also possible for an entity bean to provide an object view of an existing (legacy) application. To maintain data integrity, entity beans usually are accessed in the scope of a transaction. Contents Introduction 1 Instance life cycle 2 Transaction commit options 4 Conclusion 9 The EJB container of the Borland Enterprise Server manages the synchronization among concurrent invocations from multiple client threads; the bean provider need not be concerned with this fact. To support concurrency, the EJB container creates as many instances of entity beans as there are simultaneous transactions; this is one of the strengths of EJB container implementation (for both EJB 1.1 and EJB 2.0) by Borland. Some vendors serialize access to a single entity bean instance, limiting scalability.

2 Clients Figure 1: Serializing access to an entity bean. EJB container Single entity bean instance As the preceding figure shows, some vendors attempt to solve the problem of synchronizing concurrent client access to entity beans by serializing access to a single entity bean instance. However, this solution is not scalable since a single entity bean instance cannot efficiently service requests when the number of clients increases. Note also that this solution is imperfect when the EJB container is clustered. EJB container of Borland Enterprise Server Instance life cycle The EJB 1.1 and EJB 2.0 specifications define three states for an entity bean instance: Does not exist Pooled state Ready state In the following sections, we discuss each of these states and how the container moves entity beans among the various states. Does not exist The does not exist state is not particularly interesting, as this is the state an entity bean is in before it is instantiated. This state is analogous to nothingness. Pooled state The pooled state is where an entity bean s life starts, when the EJB container instantiates the entity bean. After creating an instance, the container then invokes the setentitycontext(entitycontext) method to pass the created instance a reference to the EntityContext interface. The pooled state is where an entity bean instance is not associated with a primary key. Clients Figure 2: How the EJB container of Borland Enterprise Server handles simultaneous client requests. As the above figure shows, the EJB container of Borland Enterprise Server creates as many instances of entity beans as there are simultaneous transactions. That is, these instances run in parallel, servicing client requests more efficiently. ejbfind (args) ejbselect (args)* ejbhome (args)* * EJB 2.0 only Figure 3: Pooled state. DOES NOT EXIST Step 1: newinstance() Step 2: setentitycontext(ec) 2

3 Beans in this state can be used to execute methods in the home interface. Note that a call to methods in the home interface will result in the instance remaining in the pooled state. The property ejb.maxbeansinpool controls the number of bean instances in this state, with a default setting of When the container starts up (or is restarted), there are no instances in the pooled state. That is, the pool is filled lazily in the Borland Enterprise Server. The number of entity bean instances in this state increases as required, depending on access by various clients. Ready state An entity bean is in the ready state when the instance is associated with a specific object identity. In other words, the given entity bean instance is associated with a primary key. Let s extend this aspect of the EJB specification with our own visualization for the sake of clarity. Assume there are two sub-classifications of bean instances in the ready state: Cached state Transactional state Cached state The cached state is where an entity bean instance is associated with a primary key. Depending on the transaction commit option (discussed in the next section), the bean instance might also be associated with state (state means the persisted fields other than the primary key). The size of this cache is governed by the ejb.maxbeansincache property, with a default setting of As in the pooled state, the number of entity bean instances in the cached state is filled lazily as new primary keys are encountered. If the application uses a small table or a few rows from a given table, often far fewer than 1000 beans are typically in use. For performance reasons, you may want to increase the size of this cache since it increases the likelihood of a cache hit (i.e., the given item could be retrieved from the cache). Caveat: Too many entity bean instances in memory may start to impact garbage collection, although this depends on the configuration of the Java Virtual Machine (JVM ) and hardware. Figure 4: Cached without state. Transactional state ejbactivate() CACHED WITHOUT STATE The transactional state is where entity bean instances actually execute business methods. Beans in this state are always associated with a transaction and typically return to the cached or pooled state at the end of the transaction. ejbpassivate() ejbactivate() CACHED WITHOUT STATE Figure 5: Transactional state. ejbload() ejbstore() As seen in the figure above, the entity bean instance in the Cached without state knows only about its primary key and not the values of its persisted fields. The value of these persisted fields needs to be synchronized with those in the database; this is accomplished via a call to the ejbload() method. Once the ejbload() is performed, the entity bean will have all the persisted fields in sync with those in the database (for that transaction) and can then execute business methods. 3

4 ejbpassivate(): This disassociates the bean from its primary key, i.e., the bean instance returns to the ejbpassivate() ejbactivate() ejbremove() pooled state. CACHED WITHOUT STATE ejbload() ejbstore() business methods ejbselect (args)* * EJB 2.0 only Step 1: ejbactivate() Step 2: ejbload() Step 4: ejbstore() Step 5: ejbpassivate() Figure 6: Transactional state transitions. Transaction commit options There are three transaction commit options defined by the EJB 1.1 and EJB 2.0 specifications. These are commit options A, B, and C. We start with option C, as it is the simplest behavior. Option C In option C, the cache is not used, that is, the property ejb.maxbeansincache is ignored. Entity bean instances in this pool wait for something to do. If a call on the home interface occurs, the entity bean executes against an instance from this pool which is in fact the behavior for all commit options. If a business method is invoked by a client, the following sequence of calls is made: ejbactivate(): This associates the bean instance with a primary key. ejbload(): This associates the bean instance with the state in the database i.e., the persisted fields in the entity bean are synchronized with those in the database. Following the above two calls, the business methods are executed in the scope of that transaction. When the transaction ends (i.e., the transaction commits), the following sequence of calls are made: ejbstore(): This updates the database with the changed values (if any) of the entity bean instance s persisted fields. Step 3: business method(s) Figure 7: Option C bean states. Option B Option B is the default behavior of Borland Enterprise Server. Here, bean instances are kept in the cache: the bean instances are associated with a primary key, but the state of an entity bean s persisted fields are not synchronized with the values in the database. When a client invokes a business method, the EJB container checks its cache to see whether a corresponding bean instance (identified by its primary key) exists. If so, then that cached instance is taken out and used. The ejbload() is invoked on this cached instance to synchronize its state (persisted fields) with those in the database. If the cache does not contain an instance associated with that primary key (either because the bean associated with that primary key has not been accessed previously or because some other concurrent transaction has already taken the bean instance out of the cache for its own use), then a bean instance is transitioned out of the pooled state. In this case, the ejbactivate() is called to first associate the bean instance with a primary key, then followed by a call to ejbload() to synchronize the state of the entity bean with the state in the database. 4

5 Client business method EJB container in Borland Enterprise Server PK=2 PK=8 PK=5 Cached without state Pooled state As indicated by the figure above, once the entity bean in the transaction ready state executes the business method(s), the container calls the ejbstore() and sends the bean back to the cache. It is possible that the bean instance enters the pooled state after ejbstore() is called by calling ejbpassivate(): this would happen if there already existed an entity in the cache for the given primary key. Figure 8: Option B client invokes business method In the preceding figure, assume that the cache of the EJB container holds three instances of an entity bean, each with its own primary key (the entity bean instances only know their primary keys). Assume that there are a number of bean instances in the pooled state; these instances are not associated with any primary key. Option A Option A provides optimized data access in cases where the EJB container has exclusive access to the database or where the underlying data is either read only, or insert only. In other words, this option provides optimized data access in cases where existing rows in the database are not modified (though new ones could be inserted over time). The following sequences of events occur in the EJB container of Borland Enterprise Server when a client invokes a business method on an Option B entity bean: Does the entity bean referenced by the client exist in the cache? ejbload() Yes, so get it out of the cache CACHED WITHOUT STATE execute business method(s) ejbstore() ejbactivate() ejbpassivate() No, so get any instance out of the pool In this case, the container uses a cache to hold the beans associated with a primary key. However, when Option A is used, the entity beans are also associated with the state in the database. In other words, the entity bean instance not only holds the primary key field but also the values for all its persisted fields. The handling of Option A by the Borland Enterprise Server is very similar to the handling of entity beans using Option B. As with Option B, when a client invokes a business method, the EJB container first looks in the cache. If the entity bean instance matching that primary key identity is found, the instance is taken out from the cache and used. It should be noted that if the cache does contain the required entity bean instance, then a call to the ejbload() can be avoided because the state of the bean is known to be consistent with the state from the last committed transaction. If the entity bean instance cannot be found in the cache, then the EJB container gets an instance from the pool and calls the ejbload() to load the state from the database. Figure 9: Option B handling request internally by the container. 5

6 Client business method EJB container in Borland Enterprise Server PK=2 PK=8 PK=5 Cached with state Figure 10: Option A client invokes business method. Pooled state In the figure above, the cache contains three entity bean instances. These instances are associated with their primary key and with their state in the database. The pooled state contains entity bean instances that are not associated with any particular primary key. The following sequences of events occur in the EJB container of Borland Enterprise Server when a client invokes a business method on an Option A entity bean: Does the entity bean referenced by the client exist in the cache? Yes, so get it out of the cache No, so get any instance out of the pool Combining the facts that (a) Option A can suppress reads from the database (when that instance is present in the cache), and (b) the difference detection engine in the Borland implementation for CMP eliminates writes to the database (i.e., eliminates updates in the ejbstore() method) when no fields were modified, demonstrates how our product provides entity bean support with no database access. In other words, a pure middle-tier data cache! Putting Option A beans back into the cache can be a bit tricky. The Borland Enterprise Server uses a first out, last in algorithm the first transaction that wants to use the bean instance gets it from the cache. If a subsequent transaction(s) requests the same bean instance from the cache, we get a cache miss because the first transaction has already removed the bean instance from the cache. The cache miss implies that a bean instance has to be retrieved from the pool, then is followed by a call to ejbactivate() (to associate the instance with its primary key) and more importantly an ejbload(). That is, only the first transaction needing a particular bean can avoid an ejbload(). Concurrent transactions must get that bean from the database. execute business method(s) Step 1: ejbactivate() Step 2: ejbload() Figure 11: Option A handling request internally by the container. Subsequently, the last transaction to complete successfully puts the bean back in the cache. The implementation of Transaction Commit Option A by Borland provides the benefits of exclusive database access without the need to serialize entity bean access. Serializing entity bean access implies that a single entity bean instance (in the ready state) services client requests in a serial manner. As mentioned in the beginning of this paper, this is not a scalable option. 6 The following figure shows how the EJB container handles Option A entity beans accessed by concurrent transactions, labeled T1 and T2. The contents of the cache and the state of the entity bean are shown. Also illustrated is the way the last transaction to complete successfully puts the state associated with that entity bean instance back in the cache.

7 T1 get bean: 2 modify state (x) to z commit transaction T2 get bean: 2 not found, get from DB modify state (x) to y commit transaction Cache empty Figure 12: Option A writing back to the cache from multiple transactions. bean state (in cache) State = x State = y State = z The EJB 1.1 and 2.0 specifications actually suggest that Option A can only be used by serializing access to a single entity bean instance. The fact that the Borland Enterprise Server, AppServer Edition provides concurrent access to Option A beans (i.e. without the need for serializing access) correctly is cool! So far we have discussed only the settings in the EJB container of the AppServer Edition to limit the number of bean instances in the pooled state or cached state. As we have discussed, the EJB specification mentions the three states possible for an entity bean. The last state, the ready state, is split into two: cached state and transactional state. So, in effect, there are four states possible from our perspective: 7 Does not exist Pooled Cached (may be with or without state, i.e., with state when Option A is used and without state when Option B is used) Transactional state In the following section, we discuss an interesting feature of entity bean support that limits the number of entity bean instances in a transaction. The ejb.maxbeansinpools and the ejb.maxbeansincache properties control the pooled state and cached state, as mentioned above. The flag ejb.maxbeansintransactions governs the number of bean instances possible in the transactional state. Typically, you would use this flag when you run a batch-style operation, such as if you were running through a large number of entity beans in a single transaction. For reasons of performance and isolation, you might want to run such batch-style operations in a single transaction. Until now, we have seen cases where beans were returned to the cache or pool only upon transaction completion. The most common concern when running batch transactions that access a large number of entity beans is the resource usage in terms of memory increasing substantially. The property ejb.maxbeansintransactions controls the number of entity bean instances in the transactional state that are actually allocated to active transactions. The default size is 500, which is half the default size of the bean instances in the pool/cache. So if the default sizes of the pool/cache were changed, then the ejb.maxbeansintransactions value should probably be adjusted accordingly. The way this property works is as follows: when a transaction accesses an entity bean, the entity bean instance is usually allocated to that given transaction. However, before the entity bean instance is allocated to that transaction, a check is made to see whether the number of entity bean instances in the transactional state exceeds the

8 ejb.maxbeansintransactions value. If so, then other beans in the current transaction are moved to the cache/pool by calling ejbstore() or ejbpassivate(), depending on the commit option selected. In effect, the ejbstore() or ejbpassivate() is not called at the end of a transaction but rather when the number of entity bean instances exceeds the limit set by the ejb.maxbeansintransactions property. As the following figure shows, the elements that are light in color represent the number of beans in the cached state (the default limit is 1000). The elements within the smaller window, in a darker shade, represent the number of bean instances in the transactional state. The number of bean instances in the transactional state (the size of the smaller window) is governed by the ejb.maxbeansintransactions property. In effect, the EJB container dynamically slides the window of active beans as well as the window of cached beans across the total items in the data set. For example, your session façade could initiate a transaction and call an entity bean s finder method that returned 100,000 rows. The session bean would then iterate through the finder collection, get the data from the entity bean, put these in some kind of a data structure, and return them to the client. Instead of instantiating 100,000 objects (as many vendors do) the EJB container instantiates only 500 objects (or whatever the size of the ejb.maxbeansintransactions is set to be) and caches a subset of the total rows (the subset has a default of 1000 instances associated with the primary key, not the state). Instances are moved from the transaction state to the cached state, based on the Least Recently Used (LRU) algorithm. Large-scale performance tests have shown that this implementation provides a good space/time tradeoff. The strategy is extremely effective at keeping batch-style operations running in a controlled amount of memory without impacting the performance of other types of transactions that do not exceed their transactional limits. Total rows (e.g. result of a finder method) Bean instances in transactional state Bean instances in cached state. "window" size governed by ejb.maxbeansintransactions value "window" size governed by ejb.maxbeansincache value Figure 13: Use of ejb.maxbeansintransactions property. In the CMP 1.1 engineof Borland Enterprise Server, we read all the results from the JDBC ResultSet at one time. That is, if there were 100,000 records, we would read all 100,000 records from the ResultSet immediately, but only instantiate as many entity bean instances as there are set by the ejb.maxbeansinpool property. In the 5.x version of Borland Enterprise Server, which supports the EJB 2.0 specification, we lazy-load from the ResultSet also. That is, we do not scroll through the ResultSet returned by a SQL query when the finder executes. Rather, we scroll through the ResultSet as and when the caller requests more items. 8

9 Conclusion So, what should you do to optimize your application? The first question is to determine whether your EJB container can use Option A. The answer would be based on whether it is possible to have exclusive access to the database or whether certain tables (or beans) are either read only or insert only. The next consideration is to determine which kinds of memory constraints you might have in your deployment environment. If your deployment environment provides only a small amount of memory, you might want to reduce the size of the cache and pool, likewise reducing the number of beans in transactions. Option C will consume less memory than Option B due to the fact there is only a pool and no cache. Note that caches are effective only if there is a high likelihood of a cache hit (i.e., an item can be found in the cache). So, if your application exhibits locality of reference as do most real world applications, then Option B is preferable to Option C. Benchmarking clients typically access entities at random, in which case Option C might be preferred. And, of course, if you have batch operations, you might want to consider the impact of ejb.maxbeansintrasanctions property. The Java ECperf benchmarking exercise conducted on the AppServer Edition has demonstrated that the default entity bean configuration in the EJB container of Borland Enterprise Server is quite effective. Borland used the default configuration for all entity beans in the ECperf test and found excellent results. We did try changing a number of variables, including trying Option C instead of Option B (Option A is disallowed by ECperf run rules), and varying the pool/cache sizes. In all cases, we found that such changes either hurt performance or had no measurable impact. So, unless there are significant memory constraints or unless Option A can be used, it is recommended that the default configuration be used as a starting point for performance optimization. 100 Enterprise Way Scotts Valley, CA Made in Borland Copyright 2002 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other marks are the property of their respective owners. Corporate Headquarters: 100 Enterprise Way, Scotts Valley, CA Offices in: Australia, Brazil, Canada, China, Czech Republic, France, Germany, Hong Kong, Hungary, India, Ireland, Italy, Japan, Korea, the Netherlands, New Zealand, Russia, Singapore, Spain, Sweden, Taiwan, the United Kingdom, and the United States