Sometimes it's easier to ask

While waiting for something to compile at 1am on the night before the night before Christmas, I came across Andrew's brush with JBossTS. There are some interesting quotes, like "JBossTS hasn't been built or developed using eclipse as far as I can tell" (JBossTS began life years before there was such a thing as Eclipse), and "Documentation surrounding great software tools is sometimes just laughable" (I like to think our docs are pretty good, given they've been updated for the past 20 years; but nothing's perfect) but overall I understand some of his concerns. The blog trail hasn't been updated since July, but if you're still struggling with this, get in touch here or ask questions on the Design Forum: I'd be more than happy to help fill in the blanks and maybe in the process improve JBossTS based on your feedback.

Transaction Processing in a Service Oriented Architecture

This should be an interesting cross post about the evolution of transaction processing and how it has been shaped by Web Services and SOA.

A minor rant around stand-alone transaction management and standards

Over the past few years there's been a backlash against application servers (both commercial and open source), with some people saying they're too heavy-weight. I'm not going to get into that argument here, but what does surprise me is the number of open source transaction managers that are trying to differentiate themselves on this very fact, as if it was something new and wonderful. Well guys I hate to break it to you but we, IBM, BEA and a few others have been doing that for years. In the open source arena, JBossTS was the first to run outside of an application server simply because it began life before there was such a thing! We've continued that over the intervening years, but maybe I just need to make it more explicit: JBossTS does not require any application server within which to run. I'm pretty sure I mentioned this before, but it's also highly embeddable, which we have proved time and again (yes, footprint size is very small, but the architecture is designed so that it doesn't require anything from the underlying environment).

Then there are some transaction service implementations (typically open source, but not exclusively) that seem to need to try to differentiate themselves by pouring scorn on transaction standards like OTS/JTS or WS-T: guys, if you have problems with these things then get involved in the process, but don't cry foul because the rest of the industry (and users) have got together to develop them. Oh, and yes while it's true that JBossTS has been at the forefront of these (and other) standards since the start, the architecture is not built on any of them since, once again, with the exception of XA they all came after JBossTS (aka Arjuna) started life.

Now maybe we don't go around "blowing our own trumpet" enough, but I think that's got a lot to do with our background: in academia there's a heavy peer review process that permeates throughout everything you do and unsubstantiated statements quickly become something you avoid like the plague. We've had 20+ years to document what we've done in this way, so everything has been verified and screened for accuracy. Maybe we assume too much that people will check that backlog of information, particularly in this day and age with so many good internet search engines. However, maybe we need to change that and start revisiting our previous publications and discussions more to refresh people's memories.

So if you're a user looking for some or all of the following: power, configurability, performance, openness, pedigree, flexibility, excellent documentation, standards (where necessary), extensibility, embeddability, stand-alone or application server deployment options, continuous vision, knowledge base, 24x7 support, etc. etc., then there really is only one option: JBossTS. TIBCO, webMethods and many others over the past 20+ years have made the JBossTS choice and found it to be the right one.

Heuristics, one-phase commit and compensations

Another cross post that may be of interest.

WS-AT and SOA

Just a cross post.

XTS update

It's nice to see that there are other commercial and OSS vendors looking to provide new implementations of WS-TX. However, it is worth stressing the points I made earlier: not only was XTS the world's first Web Services transactions implementation, but it is the only open source implementation that has been tested for interoperability with IBM, Microsoft and others. So if interoperability with heterogeneous implementations is important to you, come talk to us.

Trying to put JBossTS into perspective: XTS

Up to this point we've covered the core engine component, the local JTA, and then the JTS and remote JTA implementations. That leaves XTS: the Web Services transactions component.

There has been a Web Services transactions component in JBossTS since it's HP days, when it was called HP Web Services Transactions (HP-WST). Once again it was the world's first Web Services transactions product. At that time it was based on the OASIS Business Transactions Protocol (BTP), which didn't get the support of major vendors. Over the intervening years we tracked, authored and influenced BTP, WS-CAF, WS-T and then WS-TX. Each time, we used XTS as the platform for testing these protocols.

Just like the local JTA and JTS implementations, XTS leverages the core engine. It has no dependency on CORBA. It has no dependency on JTA. As well as webMethods, others have used XTS successfully in the past too. Because all of the various Web Services transactions specifications/standards have included support for extended (non-ACID) transactions, XTS is able to exploit yet more of the power of the underlying core engine: the ability to relax all of the ACID properties in a controlled manner. So unlike other vendors, we have the same core engine providing the support for all of the transaction models!

Then of course there's end-to-end transactions (E2EX as we were calling it in HP). We've been talking about transaction bridging for many years and working on one prototype or implementation after another. But the recent work that Jonathan et al have been doing has really pulled everything together into a more coherent approach, at least as far as JEE is concerned.

I could say more about the architecture of all of our components. I could also wax lyrically about recovery or extended transactions. But most of what I'd say is covered by the various hyperlinks I've embedded throughout these entries. So please follow them and read up. If you've got any questions or comments, put them against the relevant entry or post in our forums. But overall, enjoy using JBossTS as much as we've enjoyed developing it over the past 20 years.

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.

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.

Trying to put JBossTS into perspective: the core

There have been a few comments on the forums recently asking how the various components within the JBossTS suite relate to one another. So I thought I'd try to put everything into context here so we can at least refer back to it if these questions come up again in the future. However, there's potentially a lot to say, so I'll split it across a few entries.

Note that these entry won't go into transaction basics: this is purely about the product and it's architecture.

You'll find a lot of this information in the various collatoral documents and presentations we've got. Plus, the documentation that ships with the product is very extensive and does cover this to one degree or another. So don't think this entry is a substitute to doing your homework.

Where to start? Well if you're interested in seeing the overall architecture we have a good description, but I think it's best to start at the beginning: ArjunaCore. As it's name suggests, this is the core of JBossTS: everything that needs transactional capabilities builds on this in one way or another. Using ArjunaCore you can get full transactional semantics for your applications in a local environment. You also get:

• Multi-threaded: transactions can have many threads operating within them concurrently.


• Nested transactions: transactions may be nested within one another. This allows for improved fault-tolerance the failure of a nested transaction does not automatically undo the work of the parent transaction) and modularity (nesting is transparent to applications, such that an object that requires transaction support can be constructed without a requirement that it must be invoked within a transaction: if it is then it's own transactions will simply be nested within the invokers and if it is not then the transactions will be top-level).


• Highly configurable: one of the key components to the performance of any transaction system is its log: the transaction log is used at many times during the lifetime of a transaction and the information it stores must be durable. Thus, disk I/O is a typical bottleneck to any transaction system. However, the usage patterns for transactions can also affect the log such that different log implementations perform better for different applications. Therefore, rather than provide a single log implementation, ArjunaCore allows different implementations to be plugged in at runtime to best suite the application requirements.


• Relaxation of properties across the ACID matrix: all of the ACID properties can be relaxed in a controlled manner. So, for example, the atomic nature of a traditional transaction can be modified to support OASIS BTP cohesive transactions. Furthermore, this means that the same transaction coordinator can be used to support many different transaction models. ArjunaCore provides the necessary support for BTP, but can also be used to support the various WS-CAF (or WS-T) transaction models.


• Optimised and performant: ArjunaCore has been developed in one form or another for over 15 years. In that time, it has been tuned and optimised to improve its performance.


• Adaptable failure recovery: arbitrary transactional resources can be enlisted with ArjunaCore transactions and recovery mechanisms can be provided that will be automatically driven by the failure recovery sub-system.


• No dependency on XA participants: it defines a neutral two-phase aware interface for transactional participants that does not mandate XA semantics.

Note, it is important to realize that ArjunaCore does not require any other software in order to run. It is a complete 100% pure Java implementation of a transaction system and does not require an ORB or application server in order to provide any of its functionality.

As a result of its flexibility, our core engine has been used within mobile transactions (it has a very small footprint and still runs on an HP Jornada 720), JMS implementations, JTS, JTA and Web Services transactions (supporting more than just ACID transactions).

Hopefully that's enough on ArjunaCore. Next entry I'll move "up" to our local JTA implementation.

TIBCO BusinessWorks and JBossTS

I can't remember why I let this slip by last year, but it's still worth mentioning: TIBCO BusinessWorks uses a version of JBoss Transactions for its transactional capability. It's a long story, going back to my Arjuna days, but we worked closely with those guys for a long time before finally signing them to use ArjunaTS, the old name for JBossTS. The rest, as they say, is history.

JBossTS, Hibernate and JBossCache

The JBossCache and Hibernate folks have been doing some great integration work recently that has called for JBossTS. Galder has written a nice summary. Check it out.

Transactions and cars

I was on vacation a couple of weeks ago, SCUBA diving in Lanzarote. Had a great time and didn't think about work once. However, on the way home we were shuttled to the airport in a mini-bus and my mind started to wander back to work. JBossTS 4.2.3 will be the default transaction manager in JBossAS 4.2 and as a result we've been having some interesting discussions with clients about the impact this will have on them. I've written before about why transactions are needed and why this necessitates recovery and durability. However, there are still times when I feel that an everyday analogy may make things easier to explain to people, particularly those who aren't as immersed in transaction principles.

So there I was in the mini-bus and I began to think: cars are something almost everyone knows about and probably interacts with on a daily basis in one form or another. Therefore, is there something in the architecture of a car that plays a similar role to transactions in that you take it for granted, probably don't even think about it, maybe don't use as often as you really should, reckon you can do without because you rarely (if ever) see the need, and yet if it wasn't there you'd regret it and in all likelihood never go without it again? These things are often easier to write about in retrospect, because the list I just gave took me about 20 minutes to forumlate during that trip back to the airport.

There may be more than one answer, but the one I came up with seems fairly obvious: the seat belt! Unless you live in a country that mandates wearing of seatbelts, you may not wear them often, if at all. Even if you do wear them, how many times have you really tested that they work the way they should? You just expect them to. (Most of the people in our mini-bus were not wearing their seatbelts.)

Of course in many countries there are laws that define the safety characteristics of seatbelts, so they should work well enough. But what if there were no such laws, or you lived somewhere they didn't exist, or the manufacturer decided to cut corners? (Can you say: transactions without recovery?) Because accidents (failures) don't happen all that often, the vast majority of the time you (and the vast majority of people) wouldn't care about defective or sub-standard implementations. But when the time comes for them to work and work well enough to protect your life (or critical data), that's when you would complain if they didn't (assuming you survive). You wouldn't complain at having to pay for more saftey features within your car (or mini-bus) or any slight overhead such things may incur. So why complain about adding transactions and recovery?

I haven't tried this analogy yet with any of our customers, but it'll be interesting to see if it makes it easier to explain the differences between the old and new transaction implementations provided by JBossAS.

Welcome

Welcome to the JBossTS team blog site.