Nested transaction support

For well over 20 years we've been saying that JBossTS (aka ArjunaTS aka Arjuna) supports nested transactions. If you check out most of the papers, documents or presentations that have been written on the subject over the years they'll all tell you that nested transactions (subtransactions) are good because:

• fault-isolation: if subtransaction rolls back (e.g., because an object it was using fails) then this does not require the enclosing transaction to rollback, thus undoing all of the work performed so far.


• modularity: if there is already a transaction associated with a call when a new transaction is begun, then the transaction will be nested within it. Therefore, a programmer who knows that an object require transactions can use them within the object: if the object’s methods are invoked without a client transaction, then the object’s transactions will simply be top-level; otherwise, they will be nested within the scope of the client’s transactions. Likewise, a client need not know that the object is transactional, and can begin its own transaction.

Now nested transactions have been around for a while (since the early 80's) but they have had limited adoption outside of academia. We did manage to get them adopted within the OTS, even if in a fairly brain-dead/limited approach. But other standards either ignored them (e.g., XA) or made such vague statements about them as to be useless (e.g., JTA). The reason for this is mainly because database vendors have not traditionally supported nested transactions and is primarily why I'm writing this blog entry: I've noticed a few new transaction manager implementations that say they support nested transactions. But what does that actually mean?

If you look at either the JBossTS architecture or even the OTS interfaces, there's not a lot you have to do to the coordinator in order for it to support a parent-child relationship. That's the easy part! (In fact it's easier for the coordinator to support nested transactions because there's no requirement for durability.) But as with a top-level transaction implementation, you need participants (e.g., databases) to be able to do anything useful. The semantics of nested transactions (relaxing ACID properties) mean that a top-level aware participant can't be used for a nested transactions (e.g., your database is going to write the state changes to disk when the XAResource is driven through 2PC and what about lock inheritance?)

Thus whenever we said "JBossTS supports nested transactions" we meant that the coordinator had the parent-child relationship, but we also provided nested transaction-aware resources. Rather than doing very little to the coordinator and pushing most of the real effort on to the application developer or resource implementer, we provide a complete toolkit for developing transactional applications. As a developer you don't have to worry about whether or not a transaction is nested and whether or not you've got nested transaction-aware resources in the mix somehow. All of that is taken care of by JBossTS. So be careful if you come across a transaction manager that says it "supports" nested transactions: it's a meaningless statement unless this covers the coordinator and participants (state and concurrency control). And of course you want to do this in a distributed environment as well as in a flexible manner! (Yes, we do that too!)