Peter Holditch

A common complaint in the transaction newsgroup is, "I've done my database updates in a JTA transaction, but they didn't complete as a unit!"

In many cases, the explanation for this unfortunate loss of ACID is that the database connections that were used in the logic weren't obtained from a transactional data source, or Tx Data Source as it's abbreviated in the console. The shorthand explanation for this is that any database connection that is to participate in a distributed transaction needs to expose an xa interface, so you need a data source that can pass back an xa connection and that references a pool of xa database connections. The data source that is capable of passing through an xa connection is, you guessed it, the Tx Data Source. The bottom line: when you set up a database connection, use a Tx Data Source and an xa-compliant jdbc driver if there's any chance that you want to access it in a distributed transaction. In fact, I would boldly go so far as to say that you should always use xa drivers (where available) and Tx Data Source data sources to avoid future problems as code and infrastructure reuse change the interactions between the elements of your system.

By way of illustration, the example server shipped with WebLogic Server 7.0 provides a demo connection pool of connections to the PointBase sample database called demoXApool. The Driver class name used by this pool is com.pointbase.xa.xaDataSource, which is the name of the PointBase driver class that exposes the xa interface. This pool is in turn accessed through the Tx Data Source called examples-dataSource-demoXAPool, which exposes the xa capabilities of the PointBase driver up to the calling layers, allowing database updates to participate in JTA distributed transaction processing.

Get Something for Nothing?
If you've been following this example in your console, you may have noticed a checkbox in the configuration of the Tx Data Source entitled "Emulate Two-Phase Commit for non-XA Driver". If you were feeling optimistic the moment you saw that, your mind may have started racing and you may have reached the conclusion that if you have a non xa-capable driver, you need to simply check this box and all will be well, by virtue of WebLogic Server's ability to somehow emulate xa at the click of a checkbox. If so, my friend, I advise you to wake up and smell the heuristics, preferably quickly, before you lose the integrity of your valuable business data. You may have been led even more quickly to this conclusion in the 6.x versions of the server where, if memory serves, this option was simply entitled "enable two-phase commit". It would be surprising if all the effort that database vendors put into supporting the xa standard was able to be emulated simply by checking a box, and of course the world being generally free from such surprises, this is not the case.

Recall from past articles that the xa interface allows a transaction manager to commit a database transaction in two phases. Instead of just saying "commit" - the standard transaction demarcation verb available in all database drivers - the TM can, through the offices of xa, say "prepare" and then when it has finally made up its mind say "commit". Without the xa interface, there is no way to achieve this, and in fact the "emulation" of two-phase commit provided by WebLogic Server is simply to say "Yes" to an instruction to prepare and then pass an instruction to commit through to the (non-xa) database connection as an ordinary commit instruction. If all goes well, this will yield something that looks like a distributed transaction.

If all goes badly, this will be the beginning of your (or your WebLogic administrator's) nightmare. By way of illustration of what could go wrong, imagine a failure mode whereby the non-xa database gets corrupted, or fails after the prepare has happened. When the time comes for the commit call to be issued, there will be no way back. The commit will fail due to the corruption or disconnection, but by this point all the other databases will be gaily committing their own portions of the transaction, despite the loss of the update. Real ACID would demand that all the other databases roll back to preserve the transactional integrity. As you can see, we have lost our ACID, and with it our consistent data. In fact, this "simulation" will only be guaranteed to work if nothing in the processing environment goes wrong during certain critical windows around the commit processing. Since transactions are supposed to be all about recovering from failures, especially tricky failures during critical windows, the simulation is of no real value. The advice must be, use it as a convenience during development if you don't have an xa database driver at hand, but never check that box in a production system.

Last One to the Moon by Magic
So the xa transaction simulation certainly isn't anything close to magic moon dust. But there is something that isŠ Last Resource Optimization or LRO.

Imagine a transaction spanning several resources (generally, a resource is a fancy word for a database connection) where all but one of the resources are xa compliant. Now imagine that at prepare time the transaction manager (TM) was to successfully prepare all the xa resources. Without the non-xa resource, with all the prepares in OK, the decision to commit would be logged by the TM, and the commits would be issued. With the non-xa resource, we could limit the window for failure down to a very small duration if we were to log the decision and then immediately commit the single non-xa resource with a single phase commit instruction. If this single phase commit were to succeed, then we could go ahead with the normal second phase commitment of the rest of the resources. With this scheme, we would only be vulnerable to failure in the small window between the time the commit decision is logged and the time the non-xa commit completes. After that point, if anything failed, the non-xa resource would have been committed and eventually the xa resources would be rolled forward by the standard recovery processing. In fact we could go a step further and record the transaction id in the non-xa resource. Now we could recover the transaction with certainty, because during recovery processing the TM could check in the non-xa datastore to see if the non-xa commit succeeded or not - if the in-doubt transaction id was stored there, the commit happened, otherwise it didn't. On that basis, the rest of the resources could be recovered to their pre or post transaction states as appropriate.

In a world filled with nothing but xa resources, this LRO technique would be nothing more than an interesting curiosity, and most databases are xa compliant, so why am I boring you with this arcana? Well, many applications touch more than just databases - in these days of systems composed from a combination of bought and built functionality, most bespoke code accesses both databases (which are indeed generally xa compliant) and packaged applications (which generally are not). In fact, the whole point of the BEA WebLogic Platform is that most applications will involve elements of integration. In this scenario, to lever the maximum value out of the application server's transaction management capabilities, LRO would be a good feature.

A Little Bird Speaks of Clear Blue Water
As it turns out, a little bird told me that the next release of WebLogic Server is scheduled to support the small-window variant of LRO. When this is released, you will be able to build applications that use the transaction manager to protect data integrity across databases and an application view connected to an application through a J2EE CA adapter, even if the underlying application doesn't support xa. Or distribute a transaction across databases and a nontransactional message bus, or across multiple databases where one doesn't support xa, via a new supercharged version of the WebLogic jts driver.

Its features such as LRO, fitting as they do neatly beneath the J2EE API definitions without being specified by any of them, that sort the men from the boys and keep WebLogic Server ahead of the app server pack - a pack composed not only of competitive vendor's products but of open-source implementations and the like. J2EE support may be a commodity, in the same way as support for ANSI SQL in an RDBMS is, but it is in the application server beneath - the engine room of the modern enterprise - that commodity stops and clear blue water divides the best from the rest.