Beware transaction completion order

I should know better having once worked in the WebSphere Application Server transactions development team but it is easy to assume that JTA maintains consistency throughout the lifetime of a transaction. In reality though, for a distributed transaction it is impossible to ensure that all resource managers commit at precisely the same moment. The result is that, between the first and last commit, the state of the different resources is inconsistent. This can be a particular problem if one of the changes taking place under the transaction is used to trigger further processing.

Take, for example, the Claim Check pattern where, to reduce the quanitity of data transmitted asynchronously between two processes, the bulk of the data is written to a database and just a reference to the database entry passed in a message. The write to the database and the sending of the message are typically co-ordinated in a transaction to obtain atomicity. Now, if the resource manager responsible for the message is told to commit first, it is possible that someone will attempt to receive the message and de-reference the data before the database has been told to commit.

To resolve this issue, as of fixpack 9 of WebSphere Application Server Version 6.0.2, it is possible to set a custom JVM property to determine that the messaging resource manager should be told to commit last. In Version 6.1, the custom property is no longer required as this has become the default behaviour. In general though, the lesson is that you should not rely on the order in which the transaction manager will drive completion across multiple resource managers.

One Response to “Beware transaction completion order”