Trying to put JBossTS into perspective: JTS

Well if you're still with me you're either really interested in transactions and JBossTS, or lost.

So far I've covered the core transaction engine and the local JTA components of JBossTS and shown how they are related. In this entry I'll go over the JTS implementation as well as the remote JTA.

JBossTS began life in C++. In the early 1990's when the CORBA OTS was being developed within the OMG, we were involved and came up with the world's first complete OTS implementation (supporting all of the optional components). We did some pretty cool things with end-to-end transactions back then too (but more on that in a separate entry). When Java came along and we created the world's first 100% pure Java transaction service (predating JTA and JTS), we decided to do our own Java language mapping of the OTS, JTSArjuna.

JTSArjuna, which became Total-e-Transactions, HP Transaction Service, ArjunaTS and now JBossTS, is a full implementation of the OTS (now JTS). It builds on the core transaction engine and, because OTS is distributed in nature, obtains all of the distribution support from a variety of CORBA ORBs. Quite early on in its evolution we developed an ORB Portability Layer, to isolate ourselves from the differences in ORB implementations. So over the years, in C++ and Java, we've probably ported TS to most of the ORBs that have ever seen the light of day.

Anyway, the JTS component leverages the core, but doesn't touch the local JTA: it doesn't need to. As I said earlier, when we first did out JTA support it was built on top of the JTS. So we had distributed JTA from the start: local JTA was an after thought. The relationship between the remote JTA and the local JTA is the core engine.

Being a JTS implementation, it supports distributed transactions and hence distributed failure recovery. We have both top-down (coordinator driven) and bottom-up (participant driven) recovery. As I said above, we also support all of the optional capabilities within the OTS (e.g., nested transactions and interoposition), with XA interoperability and an XA TX look-alike veneer API. Plus we provide quite a few enhancements to allow the power of the underlying core engine to come out. For example, neither the OTS/JTS nor JTA support ordering of participants with the log. So when you call commit (or rollback) there is no guarantee on the order in which participants will be driven. The core engine allows you to order participants and therefore so does the JTS.

That's about all I have to say about the JTS component. There's a lot more in the shipped documentation that also goes into the details around the OTS. If you want to have distributed JTA, then this is your only route (at the moment). You don't have to use JTS via the JTA of course: you could go straight to the JTS. Plus, you can continue to mix-and-match your participants and transactions from the core with the JTS if you need to.