Sun Microsystems Inc.

9.6.9 Commit options

The Entity Bean protocol is designed to give the Container the flexibility to select the disposition of the instance state at transaction commit time. This flexibility allows the Container to optimally manage the association of an entity object identity with the enterprise bean instances.

The Container can select from the following commit-time options:

•Option A: The Container caches a “ready” instance between transactions. The Container ensures that the instance has exclusive access to the state of the object in the persistent storage. Therefore, the Container does not have to synchronize the instance’s state from the persistent storage at the beginning of the next transaction.

•Option B: The Container caches a “ready” instance between transactions. In contrast to Option A, in this option the Container does not ensure that the instance has exclusive access to the state of the object in the persistent storage. Therefore, the Container must synchronize the instance’s state from the persistent storage at the beginning of the next transaction.

•Option C: The Container does not cache a “ready” instance between transactions. The Container returns the instance to the pool of available instances after a transaction has completed.

The following table provides a summary of the commit-time options.

Note that the container synchronizes the instance’s state with the persistent storage at transaction commit for all three options.

The selection of the commit option is transparent to the entity bean implementation—the entity bean will work correctly regardless of the commit-time option chosen by the Container. The Bean Provider writes the entity bean in the same way.

The object interaction diagrams in Section 9.12.4 illustrate the three alternative commit options in detail.

Sun Microsystems Inc

Instance life cycle contract between the bean, the container, and the persistence managerEnterprise JavaBeans 2.0, Public Draft Entity

Note: The Bean Provider relies on the ejbLoad() method to be invoked when commit options B and C are used in order to resynchronize the bean’s transient state with its persistent state. It is the responsibility of the container to call the ejbLoad() method at the beginning of a new transaction and the responsibility of the persistence manager to utilize this method according to its caching strategies. The Persistence Manager may also use knowledge of the which commit option is used by a container in managing its caching strategies and logical transaction isolation options.

9.6.10 Concurrent access from multiple transactions

When writing the entity bean business methods, the Bean Provider does not have to worry about concurrent access from multiple transactions. The Bean Provider may assume that the container and persistence manager will ensure appropriate synchronization for entity objects that are accessed concurrently from multiple transactions.

The container typically uses one of the following implementation strategies to achieve proper synchronization. (These strategies are illustrative, not prescriptive.)

•The container activates multiple instances of the entity bean, one for each transaction in which the entity object is being accessed. The transaction synchronization is performed automatically by the underlying Persistence Manager during the accessor method calls performed by the business methods, and by the ejbLoad, ejbCreate<METHOD>, ejbStore, and ejbRemove methods. The Persistence Manager, together with the database system, provides all the necessary transaction synchronization; the container does not have to perform any synchronization logic. The commit-time options B and C in Subsection 9.12.4 apply to this type of container.

Figure 25 Multiple clients can access the same entity object using multiple instances

Sun Microsystems Inc.

With this strategy, the type of lock acquired by ejbLoad or get accessor method (if a lazy loading cache management strategy is used) leads to a trade-off. If ejbLoad or the accessor method acquires an exclusive lock on the instance's state in the database, the throughput of read-only transactions could be impacted. If ejbLoad or the accessor method acquires a shared lock and the instance is updated, then either ejbStore or a set accessor method will need to promote the lock to an exclusive lock (which may cause a deadlock if it happens concurrently under multiple transactions), or, if the Persistence Manager uses an optimistic cache concurrency control strategy, the Persistence Manager will need to validate the state of the cache against the database at transaction commit (which may result in a rollback of the transaction).

It is expected that Persistence Managers will provide deployment-time configuration options that will allow control to be exercised over the logical transaction isolation levels that their caching strategies provide.

•The container acquires exclusive access to the entity object’s state in the database. The container activates a single instance and serializes the access from multiple transactions to this instance. The commit-time option A in Subsection 9.12.4 applies to this type of container.

Figure 26 Multiple clients can access the same entity object using single instance