Sad, I mused - you don't often see that any more. My mind then wandered to hoping that, as technologists, we aren't somehow tacitly colluding in the erosion of the fabric that holds society together. Hmm, I seem to have come over all melancholy. Excuse me whilst I visit The Hunger Site...

Understanding JTA
That's better. Anyhow, I digress. I promised to look this month at when to use transactions and when not to. There's no better place to start than by examining where the transaction specification (JTA) fits into the whole J2EE jigsaw.

At a high level, all J2EE specifications fall into two broad categories: those providing a point technology and those providing a layer that binds a discrete set of specifications into the unified platform that J2EE defines. By way of illustration, messaging between message producers and consumers is a point problem addressed by the JMS specification. Likewise, how to manage server-side business logic accessed from a relatively large and potentially diverse client population is a point problem dealt with by EJB. In the other camp, providing a general purpose naming system for advertising and looking up "stuff" is the job of JNDI, and demarcating logical groups of data updates done using various "point solution" specifications is the job of JTA.

To cement these two classes of specifications together into a unified platform, it's important to understand how they relate to one another.

In the case of JTA, transactions are typically propagated through the XAResource extension to various interfaces. They're propagated to databases through the JDBC interface, and into messaging systems through the JMS interface; the J2EE Connector architecture provides for them to be propagated to external applications and - in the specific case of WebLogic Server - into Tuxedo applications and potentially from there to mainframe systems via the WebLogic Tuxedo Connector. Finally, with the session synchronization interface, any business logic you dream up can be informed before and after a transaction goes through the commit phase.

On the face of it, anything likely to affect the durable state of an application, can be involved in a JTA transaction. This gives application architects the possibility of dividing the work of their application into however many atomic lumps of functionality they desire, at whatever level of granularity they see.

Of course, J2EE is merely a toolkit; just because you can do something with it, doesn't mean it's a good idea. I always get enraged when I hear things like "Don't use Entity Beans, they don't work," since that seems to me to be akin to saying "Don't use boxing gloves, they don't work." While this might be seen as words of wisdom to someone starting guitar lessons, it comes across as somewhat less perceptive if said to someone on their way to a boxing ring.

Enough hyperbole. The rest of this month's column will explore how transactions might be used to best effect in an application.

Transactions and JDBC Databases
The first thing that usually springs to mind after mentioning transactions is databases. And indeed most of the time transactions are used in conjunction with one or more databases. (It's worth reflecting here on the phrase "one or more.")

The next thought, after transaction and database, is often "performance hit" and people immediately run screaming back to database local transactions. In reality, the perceived "hit" is not big. WebLogic Server optimizes commit processing to a single commit-only phase if a given transaction turns out to only be addressing a single RM instance. This means any overhead caused by a JTA transaction is largely confined to the mapping between the WebLogic Server transaction ID and the database's own notion of a transaction, which should be a fast lookup inside the database.

The benefit of using JTA transactions from the start is that, as you come to reuse your components in the future, they'll be able to participate in transactions with larger scope without requiring code changes. This is a big win in terms of maintenance cost and increased ROI through component re-use.

Whilst talking about single or multiple database instances, it's also worth considering the impact of JDBC connection pools. The transaction manager will start a new transaction branch for every connection pool it touches. This means that even if you're only accessing one physical database instance, you'll get a two-phase commit if you do so through two different connection pools. Not only dioes this defeat the one-phase commit optimization just mentioned, but typically data locked by one transaction branch isn't visible in another. This means you can access the same data twice, in the context of the transaction, and get a deadlock situation between branches of the transaction. On the plus side, however, the two branches can't cause one another unforeseen side effects by manipulating data both rely on in unexpected ways. These issues must be considered when deploying when you decide which components should be accessing which TxDataSources.

On locking, there's another thing: any data you modify as part of a transaction will be locked by the database (subject to the JDBC transaction isolation level you set) until the transaction completes. In this context, "completes" means when the second phase of the commit happens, not when your logic finishes executing. Clearly, if your customer database gets locked in one gigantic transaction, your system will come to a standstill until the transaction completes.

Non-JDBC transactions
Everything I've said about transactions through JDBC to databases also applies to transactions through the J2EE Connector architecture (CA), or through the WebLogic Tuxedo Connector to external applications. The main difference is that it's likely that additional business logic will be executed as well as persistent state being updated in the context of the transaction. There's an additional caveat in the case of J2EE Connector architecture, however: not only is the specification new, and the market for adapters immature as a result, but many applications simply don't have the infrastructure necessary to expose this kind of two-phase commit capability (shame on you, software vendors, for not building on BEA earlier!). So the idea of a completely homogeneous transaction propagated around everything in an IT infrastructure is a little far-fetched at this point. My advice: use it if it's appropriate and it's there - but don't bank on it.

Remember, now, the youth helping the old lady across the road. This situation is equivalent to doing a two-phase commit between an old lady and a youth, the goal of which is to get old ladies safty across the road. While that's a laudable objective, it's not ideal if you want to get a large number of youths across the street. In this case, you'll let the youths dodge traffic as nimbly as they can and leave the old ladies to effect their traversals as traffic permits. Even having off-loaded the old ladies, the throughput of road-crossing youths will be greatest if you don't force them to cross as a group. This is analogous to lots of small transactions, as opposed to one large one.

We're now moving into the realm of JMS and transactions.

Introduce Some Asynchronicity
J2EE CA, JDBC, and the WebLogic Tuxedo Connector are all designed to send requests and get responses in real time. In contrast, JMS is designed to send requests reliably, but at some unspecified point in the future. It would be the exception rather than the rule that logic would ever be coded to send a JMS message and then do a blocking wait for the reply - that case is better handled by RMI. What you can do with JMS is send a message as part of a transaction - so it's guaranteed to be dispatched if and only if the transaction commits successfully. You can rest safely in the knowledge that the sending transaction won't be held up by potentially large amounts of downstream logic and updates, which will be done in the context of a different transaction controlled by the message receiver. For example, if you imagine the transaction to be "open new account" and the downstream logic to be "send welcome pack by post," it's clear that the customer database updates must be committed before the mail service delivers the welcome pack. These actions, although logically both part of the same business transaction, should be decoupled. Think of your customer database as a youth, and the U.S. Postal Service as an old lady, or in short use JMS where appropriate to decouple large monolithic transactions into smaller, nimbler ones.

Another reason to use JMS and transactions combined is to protect applications from resources that don't support transactions, such as the J2EE CA cases discussed earlier. If you front-end a transaction-unaware application with a JMS queue, then you are guaranteed that it will update at least once at some future point, if and only if the update transaction commits. This avoids the potentially far-from-trivial task of backing out changes made to application state through "compensating transaction" logic if a transaction rolls back unexpectedly after a real-time update to the non-transactional system. Of course, the downside is that the transaction-unaware application must be capable of detecting multiple repeat updates, since updates could be resubmitted to it if it fails while consuming messages. This is easy if the application's behavior is idempotent (that is, calling it twice with the same input data will leave it in the same state as only calling it once) but harder in other cases. For example, a SetCustomerAddress method can be called repeatedly with the same data to no ill effect, whereas an IncreaseAccountBalance method, if called twice, will try and create money from nowhere. While this would be a pleasant surprise if the account in question is your own, it probably isn't allowed in the business domain.

Summary
To summarize, using transactions to group operations on individual components together into higher-level business transactions is a powerful technique that can promote component re-use without reducing the reliability of the overall system. (For example, allowing the transfer method to be implemented as a transaction surrounding a call to credit and a call to debit.) All powerful techniques need to be used carefully, however, and this one's no exception. Misused transactions can result in applications grinding to a halt with all their data locked. To avoid this, the architect must understand the expected scope and duration of transactions, and use techniques like JMS messaging to introduce some asynchronicity into the system.

That concludes this month's column. Next month, Transactions: the Saga Continues, on business transactions, two-phase commit, and other stories.