Extended Stateful Session Bean Lifecycle
Occasionally, there is a need for a stateful Session bean to have visibility as to the progress of the underlying transaction. Specifically, a bean might need to know
Has the transaction started?
Is the transaction about to complete?
Did the transaction complete successfully or was it rolled back?
For example, consider the age-old example of a ShoppingCart bean. In its purchase() method, it is likely to modify its internal state. Perhaps it holds its contents in a java.util.List called currentContents. On purchase(), it might move the contents of currentContents to another java.util.List called recentlyBought.
Suppose, then, that the transaction that actually modifies the persistent data store fails to complete. Maybe the shopper doesn't have enough limit left on his or her credit card. Because Session beans are not transactional, the ShoppingCart bean needs to know that it should reset its internal state back to the beginning of the transaction. In other words, it needs to move the contents of the recentlyBought list back over to currentContents.
Obviously, there is no issue for stateful Session beans deployed under BMTD, because they are the owner of the transaction anyway and know when the tran.begin() and tran.commit() methods will be invoked. But for CMTD Session beans, there is an issue.
The EJB specification addresses this by extending the lifecycle of the bean. If a stateful Session bean implements the javax.ejb.SessionSynchronization interface, three additional lifecycle methods are defined and will be called at the appropriate points:
beforeCompletion() The transaction is about to be committed.
afterCompletion(boolean) The transaction has completed. The boolean argument has the value true to indicate that the transaction was committed, or false to indicate that the transaction was rolled back.
Figure 8.5 is a reworking of Figure 5.14 that you saw back on Day 5. It shows the stateful Session bean's view of its lifecycle. (The client's view and the actual lifecycle managed by the EJB container are unchanged).
Figure 8.5. The Session Synchronization interface gives the stateful Session bean visibility to the transactions managed under CMTD.
One common pattern for using this interface is to use the afterBegin() method to load any data from the data store (perhaps in the form of Entity beans), and then use the beforeCompletion() method to write any cached data that may have changed. One immediate application might be with respect to multi-valued cmr-fields. You will recall from yesterday that collections returned by the getter method of a cmr-field are valid only for the duration of a transaction. These two methods scope the duration that such a returned collection can be used.
There are analogies here also with SQL, where the afterBegin() corresponds to a SELECT … WITH HOLDLOCK statement, and beforeCompletion() corresponds to the UPDATE statements.
If the SessionSynchronization interface is implemented by a Session bean, the only allowable values for the trans-attribute element in its deployment descriptor are Required, RequiresNew, or Mandatory. This is because these are the only attributes that can guarantee the presence of a transaction.