However, thanks to the inefficiencies of natural selection (humanity is not perfect yet) and the beauty of entropy (all things decay), failures will always happen and so transactions will always be needed: all we can ever hope to do as technology advances, is reduce the probability of a failure occuring. Therefore, as a developer you've got to weigh up the likelihood of a failure (any failure) happening and corrupting your application versus the perceived cost (commercial and the overhead of restoring the system to good health) of using transactions. If you want to take the risk, then don't use transactions; but likewise, don't forget that they do exist to help you.

Now you may think that replication of resources/objects/servers could be used in place of transactions, but that isn't the case. Replication and transactions can be complimentary, but they're not a replacement for one another. Transactions guarantee consistency even in the presence of complete system failures, but you won't necessarily get forward progress. However, replication offers (though cannot guarantee) forward progress in the presence of a finite number of failures. So I would argue that if you are replicating updatable data, then you should definitely consider transactions as well.

Transaction processing systems have been the backbone of significant areas of computing infrastructure for decades. A lot of these places (finance, telecos etc.) made the trade-off between performance and reliability because there was never a trade-off to be made: if they corrupt data (e.g., lose updates to stock trades), then institutions lose business. Now obviously that's not the case everywhere and there are applications where failures really don't matter (e.g., stateless interactions). But in general, you need to think about the effect of failures on your applications and although transactions are just one of the techniques you could use to help tolerate them, with the JTA they are a core component of J2EE. So rather than come up with ad hoc solutions, it may be better to try to leverage tried-and-tested techniques and associated implementations.

Following on from this is the oft heard statement: "everything I do is within a single VM, so I don't need transactions". This is definitely an education issue, where distributed transactions have become synonymous in the minds of many people with transactions. Most people can see that if they're accessing resources/participants across physically distinct machines or processes, there's a need for transactions to coordinate simultaneous updates to state. In a local (single VM) environment, the need is often overlooked. But it is still there: in many cases, even within the same VM, applications use and modify data from multiple different sources, and in that case, you need the benefits that transaction processing provides. Distribution just makes it more obvious that independent failures can cause problems. But they're still there in the local case; you may just have to look a little harder.

Plus, transactions get a lot of bad press for overheads that really don't exist in all cases. All commercial grade implementations support a number of significant optimisations to improve performance in the 80-20 case. For example, if there's only a single participant in a transaction, then the notorious two-phase commit protocol goes away and we run with a single phase. Then there's the read-only optimization: if a participant didn't modify any data, then it can drop out of the transaction "early". Plus, there are some implementations that have evolved over decades to offer many other performance features, such as lightweight coordinators, nested transactions and non-durable participants. The intention (mirrored by Microsoft's work with Indigo transactions) is to make transaction implementations so lightweight, with low overhead that they'll become a natural part of the infrastructure (and in the case of Microsoft, that'll mean in the operating system). We've already seen them moving into hardware, so this makes a lot of sense too.

As I've said before, think of transactions like an insurance policy: compared to how much time, money and effort you may lose by not using them, the cost of using them may be well worth it. Obviously there's a tiping point on any graph of cost of using transactions versus advantage they may bring, and that point is going to be very dependent on your application. But consider it nonetheless.

However, it was certainly the case that interoperability was still considered of secondary importance. To a degree, that is understandable: you can't worry about interoperability until/unless you have a product. However, I believe strongly that interoperability testing should be considered as important as standard unit testing and QA: it shouldn't be an afterthought.

To explain why, I'll use the Web Services interoperability fests as an example, but as I said before, this isn't (or shouldn't be) technology specific. If you've ever looked at various Web Services specifications, such as WS-CAF, WS-SX, or WS-Addressing, they're not exactly easy reading material (JEE and CORBA specifications are similar). Understanding why something is intended to work the way it does is often as difficult as understanding how and is definitely as important. As well as product development, I've been working in standards and specifications for over 10 years and two people can read the same specification and come away from it with completely different perspectives. In most cases that's a problem (read: bug) with the specification that should be caught early on. And this is where previous standards efforts, such as JEE and the OMG, fell down: more often than not, specifications were developed months or years before implementations; for example, in order to ratify a specification, the OMG only requires companies to say they will eventually use it, not that they have implemented it.

Now although the same is true for Web Services (e.g., OASIS requires at least 3 committee member organisations to say they are using a specification, though it doesn't have to be in product), the whole "Web Services are for interoperability" mantra has really taken hold. Before any Web Services specification is standardised, the various committees have at least one workshop where they work through interoperability between heterogeneous implementations and feed those results back into the specification. Obviously depending on the results, this can be an iterative process, but the end result is usually something that offers better out-of-the-box interoperability. Therefore, from a specification development perspective, these workshops are incredibly important and would be beneficial in other arenas.

Obviously not everyone can be present at these official interoperability fests and anyway many implementations arise after standardisation has occurred. Plus, standards are still not perfect and can often be deliberately ambiguous, leading to the possibility of non-interoperable implementations. That's why it is so important to do interoperability testing during development: iron out bugs in the specification or in your understanding of what was meant by the original authors. If it is left until after the product is shipped, then it may be difficult or impossible to make changes without causing problems for end-users. That's another route back to vendor-lockin and bridging protocols. Furthermore, feeding bugs back to the standards bodies will benefit the next version and other users: try arguing with one vendor that your view of an ambiguous specification is correct if they've come to a completely different (and incompatible) conclusion!

When each participant receives the first phase message (essentially asking "can you commit the work you've done?"), it must make any changes it is responsible for (e.g., table updates) durable, but in a provisional manner - the participant doesn't know the transaction outcome yet, so it had better not second guess the coordinator (this can lead to what are known as heuristic outcomes.) When the coordinator (eventually) sends the second phase message (which is either "commit" or "rollback"), the participant can clear its durable log by making provisional updates permanent (in the case of commit), or deleting them (in the case of rollback). This is obviously an simplified description of what goes on, but it should be sufficient for the purposes of this discussion.

If everyone follows these rules, then you get guaranteed completion of all participants in a transaction, even if that completion is to completely undo the work: atomicity ensures that what one does, they all do and durability (combined with a suitable failure recovery component) ensures it happens if if there are failures.

But consider what you get for this overhead: guaranteed outcomes in the presence of failures and, if you've used distributed transaction support, this happens irrespective of the physical locality of your coordinator and its participants. Think about what you'd have to do if you wanted to do this yourself. Transactions are like an insurance policy for your critical applications: most of the time you don't see the benefit, but it's that "odd" occasion where you'll be really glad you had them.

So this is where the trade-off comes. You trade off some performance for these guarantees. If you don't want the guarantees (and many applications simply don't need transactions), then you shouldn't be using transactions. If you do want the guarantees, then I wouldn't encourage you to do this yourself.

Now if we return to some of those optimisations I mentioned earlier, there are cases where durability isn't needed at all. Some transaction systems allow you to use transactions to control what are often termed "recoverable" entities: these are resources that need the consensus of 2PC, but don't want the failure recovery - if a crash happens, the data is lost and that's just fine for these types of resources. You can mix recoverable and persistent (traditional) participants in the same transaction and the coordinator should correctly write logs only for the persistent resources.

Unfortunately the JTA doesn't support recoverable participants because it is tied to XA. That's not to say you couldn't have an XAResource implementation that was only recoverable, but that the XAResource interface doesn't convey that information to the coordinator. So, even if the coordinator could optimise the log writing in the case of recoverable participants, it can't in a pure JTA environment because it can't tell the difference via the participant interface. That means that this optimisation isn't available in a portable manner.

This is about the only time in a production environment that you should be considering using transactions and not having failure recovery. If you need transactions for your application and you're using a transaction system which doesn't support recovery, or it doesn't have it enabled by default, then don't use it. One argument I've heard from some for disabling recovery or not even implementing it is: "it's faster without recovery". Of course it's faster, because it's not doing anything! You've still got the 2PC overhead of course, but without recovery (or recoverable participants), what's the point? It's like buying an insurance policy that doesn't pay out: you get the pleasure of the overhead, but you'll never see any benefit.

You could argue that for testing purposes you don't need recovery, and there may be a case there. However, if you're testing, performance shouldn't be an issue anyway. So what's a little slower response actually mean in this situation, when you actually get to test the entire system as it's going to work in a deployed environment?

Another argument I've heard is: "99% of applications don't need recovery". OK, that's fair (though I might not put it as high as that). But in that case, 99% of applications shouldn't be using transactions, because without recovery they don't get much benefit.

So after all of this, what I've tried to show is that if you want transactions then you need to be prepared to pay the cost. But the benefit in the case where you do need them, can be huge. And in that case, make sure you get the whole transaction package from your implementation of choice and worry about those suppliers who try to tell you that recovery isn't important. If you're sure you don't need recovery, then you shouldn't be considering using transactions either.

In August 2003, Sun, Oracle, Arjuna Technologies, IONA Technologies and Fujitsu, released the Web Services Composite Application Framework family of specifications. Shortly afterwards, these specifications were given to OASIS to form the OASIS WS-CAF technical committee.

In future entries I may look at the other specifications, but the one I'd like to concentrate on now is WS-Context.

Then of course there was the infamous ReferenceProperties in WS-Addressing. This allowed additional information within an address to be encoded in an opaque manner, but which could (and was) used to create sessions. The problems with this have been discussed many times elsewhere, but I recommend checking out this paper for a summary. Fortunately ReferenceProperties were removed, though ReferenceParameters still exist.

WS-Context provides a more lightweight, generalized session model, somewhat akin to that of a Web Services cookie. The Web Services architecture is not prescriptive about what happens behind service endpoints. This gives flexibility of implementation, allowing systems to adapt to changes in requirements, technology etc. without directly affecting users. It also means that issues such as whether or not a service maintains state on behalf of users or their (temporally bounded) interactions, has been an implementation choice not typically exposed to users. The WS-Context session model encourages loose coupling of services and their users and keeps any implementation specific choices about state where they belong: behind the service endpoint.