Peter Holditch

For several months now I've waxed lyrical about transactions and how they hide the complexities of distributed updates in applications, and indeed the concept of the two-phase commit transaction is a very powerful one, allowing you to make the assumption that all the transactional data stores that hold your business data will roll forward or back in lockstep.

However, as with all "under the covers" behavior (if you'll excuse a mixed metaphor), sometimes you need to get inside the kimono to get what you really need.

For example, what if you're using a bean-managed transaction from a stateful session bean to update state represented by a number of entity beans (a common case)? Although the transaction will ensure the consistency of the entity beans, since the state in the session bean is not held in a transactional resource, it is not impacted whatsoever by the transaction. Now consider the case where the transaction rolls back for some reason. Although all the databases will look as though the transaction never happened, the session bean may have state set in it that makes sense only if the transaction committed.

This sounds a bit desperate! What should we do? Throw out the stateful session bean and keep all the state in entities? Well, we could, but if we have no requirements for long-term persistence of the state, there's no reason to weigh a database down with it, and to split the state from the function would break the encapsulation that the session bean provided. You might think that there must be a more elegant solution, and there is...

JTA provides a session synchronization interface, javax.ejb.SessionSynchronization. This is how you, as an application developer, can request that JTA open its kimono to you. Through this interface you provide three callback functions that the JTA subsystem can use to notify your code of what it's doing behind the scenes. The three methods provided are afterBegin(), beforeCompletion(), and afterCompletion().

To digress a moment for the pedantic, this interface is actually provided by the EJB container. Only the latter two methods map directly onto JTA interfaces as such. In the context of a raw user of JTA, an afterBegin method would make no sense, since the transaction would begin under the control of the application code. In the EJB world, a container-managed transaction could be begun on behalf of the logic by the container, and the afterBegin() notification is the EJB container's way of letting your code know that this has happened. The "raw" JTA equivalent of this interface is in fact called javax.transaction.Synchronization.

Anyway, back to the plot... through the synchronization interface, your stateful session beans can register for notification of when the "under the covers" transactional behaviors take place. If you'll excuse another brief digression, I have a colleague at BEA who has a pathological hatred of stateful session beans. He recommends using them in only two cases: if you need to keep session state in a J2EE application and can't rely on an HTTP front end (and hence, can't use an HTTP session object), or if you need to respond to transactional events - while an HTTP session object can't easily register for these events, the EJB container provides the machinery to do this easily. The fact that this particular individual can be persuaded to use a stateful session bean at all indicates the potential power of linking to JTA in this way.

So, as you by now suspect, the typical use case of the SessionSynchronization interface is a stateful session bean with its beforeCompletion method containing an implementation that flushes any state that may have been cached before the commit processing begins (of course, if state is cached when the transaction is committed, then it will never be written to the back-end storage). The afterCompletion implementation, when the final result is a JTA rollback, will likely return the session state to some values saved prior to its commencement.

As a final note, the afterBegin and beforeCompletion methods are called in the scope of the transaction to which they refer, so any updates they make to transactional stores will be included in the transaction, along with whatever updates are caused by the business logic. Clearly, the afterCompletion method cannot be called in the context of the transaction since it has by that stage, by definition, completed.

"Groundhog Day" for JTA
That's all well and good - using the session synchronization interface we have a way to make our stateful session beans' state pseudo-transactional, and we have a placeholder to allow for session state to be cached at application level should this be necessary. Before the story ends and we live happily ever after, however, a few moments would be well spent thinking through the implications of that innocuous-looking previous paragraph...

Consider again that the beforeCompletion method must be called before the two-phase commit process can start. Also remember that the whole point of JTA is that an arbitrary number of objects can be bound together in a single transaction. Given this, it will quickly become apparent that the job of the JTA subsystem at commit time is to call all the beforeCompletion methods registered with the transaction before commencing the conventional two-phase commit processing with the underlying data stores also registered with the transaction. It is this characteristic that has sometimes led object-based transaction monitors to be described as performing a "two- and-a-half-phase commit."

This sounds simple until you realize that not only is the list of beforeCompletion methods dynamic, but since all of them are called in the context of the transaction themselves, any of them could cause the list itself to grow. Imagine the scenario where stateful session beans S1 and S2 both implement beforeCompletion methods. A business method on S1 is called, causing a transaction to be started and resulting in two entity beans, E1 and E2, being involved in the transaction.

Now it's commit time. The JTA subsystem goes to commit the transaction. For the first "half phase" it sees that the beforeCompletion method on S1 needs to be called. Imagine that this method calls the second session bean, S2. During the first half phase another beforeCompletion method has been added to the list. S1's beforeCompletion method returns, and the JTA subsystem realizes that S2's beforeCompletion method is now in the list and needs to be called, so JTA makes the call. If S2's beforeCompletion method has no side effects, then on its return JTA can start the two-phase commit proper. However, if S2's beforeCompletion method has invoked a method on S1, then suddenly S1's method is back in the list. Despite the fact that it has already been called, the state of S1 may have been changed by the latest call, so it will need to be called again.

You can see from this that we have created Groundhog Day for the JTA subsystem. As fast as it tries to cross beforeCompletion methods off its list, new ones are added. This will cause an infinite loop, which may provide entertainment for anyone who has sadistic inclinations toward application servers - for most normal people, this will just be a bad case of bad news. In fact, I have bad news for the sadists too... the WebLogic developers thought of this, which provides an explanation of one of the more obscure JTA configuration parameters, the "beforeCompletionIterationLimit". This parameter is set on a JTA-wide basis by the administrator and limits the number of times that JTA will loop around trying to cross beforeCompletion methods off a transaction's list before it will just give up and abort the transaction. Clearly, identifying one of these infinite loop, Groundhog Day-type situations by code inspection as a developer requires a view of the implementations of all the beforeCompletion methods in a transaction and is likely to be pretty difficult to spot and fix, particularly in situations where old beans are being reused in new transactional scenarios.

Based on this, I would propose a best practice for the implementation of beforeCompletion methods.

Safest of all will be those that do nothing but touch the in-memory state of the session bean of which they form a part. Next safest will be those that directly access XA resources (for example, by direct JDBC access through a TxDataSource to a database). The most dangerous will be those that call external J2EE components. As soon as you invoke external components, you lose control over exactly what resources will be touched, and hence potentially unwittingly send WebLogic into Groundhog Day until the beforeCompletionIterationlimit is reached. Consequently, I recommend that beforeCompletion methods do not invoke external components.

So that's all for this month, more transaction-related chat real soon ...
So that's all for this month, more transaction-related chat real soon ...
So that's all for this month, more transaction-related chat real soon ...

Oops, is there a configurable limit for this kind of thing?