Trying to put JBossTS into perspective: local JTA

I covered the core component of JBossTS earlier, so now it's the time of local JTA. Although we have two JTA implementations now, early on in the evolution of JBossTS there was only one and that was built on our JTS/OTS implementation. However, with the development of ArjunaCore and the fact that some of HP's customers didn't want to worry about configuring/maintaining an ORB, we looked at creating a purely local JTA implementation.

ArjunaCore has its own set of APIs that are not based on XA or any other standard. In fact, many of them pre-date the current standards in these areas. But as we saw in the earlier entry, there's a lot of flexibility in the core engine: if anything, it essentially presents a superset of capabilities of the various transaction specifications. So producing a purely local JTA implementation based on it was relatively straightforward. JTA is a narrowing of those capabilities, because it is closely tied to XA: the participants can only be XA participants and even with the UserTransaction/TransactionManager split there's not a lot of scope for doing "interesting" things like nested transactions or nested top-level transactions.

Both of our JTA implementations do support nested transactions. But the fact that XA doesn't support nesting makes it harder than it should be. In order to have support for nested (or sub) transactions, you need the cooperation of a nested transaction-aware coordinator and nested transaction-aware participants. Our coordinator is nested transaction-aware, because ArjunaCore has always supported sub-transactions. However, XA participants don't. But luckily for those people who want to try out this capability, you can mix-and-match your APIs with JBossTS. So you can create a JTA transaction and then dive into the core API if necessary to register a nested transaction-aware participant. Plus, ArjunaCore comes with a suite of such participants, so you don't have to write them to start with.

So there you have it. The local JTA (which ships by default in JBossAS 4.2) is a layer on top of ArjunaCore. It provides full non-distributed JTA capabilities including automatic failure recovery. Plus, if you're willing to try, it's still possible to get at the power of the underlying engine.