Sun Microsystems Inc.

9.1.10 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 caching of entity object’s state and 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 subsection 9.5.4 illustrate the three alternative commit options in detail.

Sun Microsystem Inc

9.1.11 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 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 database during the database access calls performed by the business methods; and by the ejbLoad, ejbCreate, ejbStore, and ejbRemove methods. 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.5.4 apply to this type of container.

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

With this strategy, the type of lock acquired by ejbLoad leads to a trade-off. If ejbLoad acquires an exclusive lock on the instance's state in the database, then throughput of read-only transactions could be impacted. If ejbLoad acquires a shared lock and the instance is updated, then ejbStore will need to promote the lock to an exclusive lock. This may cause a deadlock if it happens concurrently under multiple transactions.

•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.5.4 applies to this type of container.

Sun Microsystems Inc.

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

9.1.12 Non-reentrant and re-entrant instances

An entity Bean Provider entity can specify that an entity bean is non-reentrant. If an instance of a non-reentrant entity bean executes a client request in a given transaction context, and another request with the same transaction context arrives for the same entity object, the container will throw the java.rmi.RemoteException to the second request. This rule allows the Bean Provider to program the entity bean as single-threaded, non-reentrant code.

The functionality of some entity beans may require loopbacks in the same transaction context. An example of a loopback is when the client calls entity object A, A calls entity object B, and B calls back A in the same transaction context. The entity bean’s method invoked by the loopback shares the current execution context (which includes the transaction and security contexts) with the Bean’s method invoked by the client.

If the entity bean is specified as non-reentrant in the deployment descriptor, the Container must reject an attempt to re-enter the instance via the entity bean’s remote interface while the instance is executing a business method. (This can happen, for example, if the instance has invoked another enterprise bean, and the other enterprise bean tries to make a loopback call.) The container must reject the loopback call and throw the java.rmi.RemoteException to the caller. The container must allow the call if the Bean’s deployment descriptor specifies that the entity bean is re-entrant.

Re-entrant entity beans must be programmed and used with great caution. First, the Bean Provider must code the entity bean with the anticipation of a loopback call. Second, since the container cannot, in general, tell a loopback from a concurrent call from a different client, the client programmer must be careful to avoid code that could lead to a concurrent call in the same transaction context.