This month's article is again inspired by a posting on the weblogic.developer.interest.transaction newsgroup. The question (excerpted from the posting) was:

Does the <trans-timeout-seconds>10</trans-timeout-seconds> in weblogic-ejb-jar.xml apply to transactions that are in a suspended state? I have EJB1 (Container Managed/Required) that starts transaction T1 and does some work, then calls another EJB, EJB2 (Container Managed/NotSupported), which makes an interdomain T3 call. Since EJB2 is configured with NotSupported transaction attribute, transaction T1 is suspended for the time being while the business method of EJB2 is executing. The question is, if I set <trans-timeout-seconds>10</trans-timeout-seconds> for transactions started by EJB1, will it work?

The answer is yes. End of article.

Only joking! The subject of transaction timeouts and their relationship to the flow of control through an application's logic is one that often comes up, and is frequently misunderstood, so here goes another journey through "how the bits fit together."

First, a step back. As you will know if you have read my previous articles (or any other sources of information about distributed transactions), long-running XA transactions are a bad thing. Database (and potentially other) locks are held from the moment that a transaction touches the data until the point that it commits or aborts. Lots of locked data can quickly become a performance problem for any application, resulting ultimately in your whole database being locked. This is bad. The moral of that story is, keep your XA transactions as short as you possibly can to allow locks to be recycled as fast as possible.

In this context, the transaction timeout is your friend. You can set a timeout in a deployment descriptor, programmatically in your code, or via the JTA page in the BEA WebLogic console and the transaction manager will respect this timeout on your behalf. If a transaction lasts longer than the timeout permits, WebLogic's transaction manager will automatically go about rolling it back for you. The assumption is that some kind of application error (anything from a logic error to the hardware being temporarily overloaded, causing the application to run slowly) is causing the timeout to be exceeded, and that cleaning up the transaction (and thus freeing the associated locks) will help the overall health and well-being of the system.

So that's fine. That's what the transaction timeout is, and that's what it's for. Generally, tuning transaction timeout values such that transactions in a smoothly running system will never time out (by a small margin of safety) offers you a degree of protection from spikes in load and errors in logic that can turn little localized dramas into big, scary catastrophes.

As Usual, the Transaction Manager Is Your Friend
So far so clear. The confusion tends to lie with how the transaction timeout relates to other behaviors of the application server. The behaviors in question are how the timeout mechanism behaves with respect to a suspended transaction (the basis of the posting I opened with) and what happens to threads executing code on behalf of transactions that time out?

So what is suspension of a transaction? Recall that transactions have two halves. The synchronous runtime part keeps track of what application actions should be logically grouped into a transaction (controlled, by calls to begin, commit, etc.) and the asynchronous part whose obvious function is to take the list of resources collected by the runtime part and process the two-phase commit asynchronously with respect to the application flow. What the calls to UserTransaction.begin do is associate a transaction object with the current thread of execution. The fact that a transaction is associated with a thread of execution tells the application-server infrastructure to propagate the transaction along with any calls or data accesses the thread makes. A call to UserTransaction.commit disassociates the transaction object and the current thread and kicks off the two-phase commit of the (now-completed) transaction. What suspending a transaction does is simply break the association between a thread of execution and a transaction. Resuming it rebuilds the association. Thus, if you need to work outside of an active transaction, you suspend it, do the work, and then resume it when you're done.

There is one more necessary detail here: the life cycles of the synchronous and asynchronous components do not follow each other serially. Both begin concurrently when the UserTransaction.begin call is made. The synchronous part clearly ends before the asynchronous part, since the two-phase commit processing that is the latter's primary responsibility cannot begin until the synchronous piece has completed - completion signalled by calling commit.

Given the rationale I have laid out for the timeout's existence, it should be clear that the other duty performed by the asynchronous component of the transaction is timeout processing. From the moment the begin call is made, the timer starts ticking independently of the flow of your processing. When the timeout expires, the Transaction Manager will roll the transaction back. The first you hear of that happening may be when calls you make in the thread associated with the transaction start to throw exceptions, since it is not possible to propagate a rolled-back transaction (what would be the point, the results of the call will not persist under any circumstances?).

After all that, the direct answer to the question we started with is that suspending a transaction has no impact whatsoever on its timeout; it simply breaks the association between transaction and thread. If your code suspends a transaction and then goes to sleep for a week, it should expect to find that the transaction has timed out while it slept.

The Transaction Has Timed Out While It Slept
Finally, to the second relationship I mentioned - that between the timed-out transaction and the thread currently executing work on the transaction's behalf. Some people hope that if they set a transaction timeout on an operation, when the timeout is exceeded all work on behalf of the transaction will instantly stop. In an ideal world, that would happen (and WebLogic does all it can to try and stop you wasting cycles by refusing to propagate a timed-out transaction), but the world (and the world I am referring to here is the general world of java) is not ideal. So the transaction times out, and WebLogic wants to stop your thread. What can it do? Looking at the java.lang.Thread class, we quickly conclude that it can't do a whole lot. It could call Thread.interrupt, but then code inside the thread would have to catch the Interrupt and clean up - so this requires cooperation for the application code. It could call Thread.destroy, but according to the Javadoc this is not implemented (and if it was, would leave no way to clean up resources). Or it could call Thread.stop() except that that's deprecated with a mile-long health warning that talks about how stopping a thread with no controlled cleanup could lead to all sorts of inconsistent data being left around.

There is no easy answer - there isn't really a facility in J2SE or J2EE as they stand today to allow a thread to be safely and asynchronously terminated. WebLogic does what it can - the node manager will try and detect "stuck" threads to warn operators about them; the runtime will try and prevent work continuing on behalf of rolled-back transactions by throwing exceptions rather than propagating them. And, it does all it can at the JDBC level (such as calling Statement.cancel for statements running on behalf of rolling back transactions where possible) but at the end of the day - until the thread returns control to the container - there isn't much more WebLogic can do than wait.

In summary, the transaction timeout impacts the asynchronous behavior of the transaction manager only - it has no direct impact whatsoever on the flow of control within the application logic.

I have timed out again for another month. Roll back and read more next time!