Java Transaction Processing: Design and Implementation (HP Professional Series) [ペーパーバック]

Since many financial institutions have standardized on it, I hear Java is the new COBOL. Whether or not this is true, if Java is to become the business language of choice, transaction support is crucial. (By 'transaction,' I mean 'allowing two or more decisions to me made under ACID constraints: atomically, consistently, (as) in isolation and durably'.) Over the last five ears, the Java platform has grown by leaps and bounds, not least in this area.

Java Transaction Processing by Mark Little, Jon Maron and Greg Pavlik, explores transactions and their relationship with the Java language and libraries. Starting with basic concepts of transactions, both local and distributed, including the roles of participant and coordinator, and the idea of transaction context, the book covers much old but useful ground. Then, by covering the Java Transaction API (JTA) as well as OTS, the OMG's transaction API which is JTA's foundation, this book provides a solid understanding of the complexities of transactions for Java programmers who haven't dealt with anything more complex than a single RDBMS. I'd say these complexities could be summed up simply: failures happen; how can you deal with them reliably and quickly?

The book then goes on to examine transactions and the part they play in major J2EE APIs: Java Database Connectivity (JDBC), Java Message Service (JMS), Enterprise Java Beans (EJB) and J2EE Connector Architecture (JCA). These chapters were interesting overviews of these technologies, and would be sufficient to begin programming in them. However, they are complex, and a single chapter certainly can't do justice to any of the APIs. If you're new to them, expect to buy another book.

In the last section, the authors discuss the future of transactions, especially long running activities (the Java Activity Service) and web services. This was the most interesting section to me, but also is the most likely to age poorly. These technologies are all still under development; the basic concepts, however, seem likely to remain useful for some time. And, if you need to decide on a web service transaction API yesterday, don't build your own, read chapter 10.

There were some things I didn't like about Java Transaction Processing. Some of the editing was sloppy-periods or words missing. This wasn't too big a problem for me, since the publisher provided me a free copy for review, but if I were paying list price ($50) I'd be a bit miffed. A larger annoyance was incorrect UML and Java code snippets. Again, the meaning can be figured out from the text, but it's a bit frustrating. Finally, while the authors raise some very valid points about trusting, or not, the transaction system software provider, I felt the constant trumpeting of HP and Arjuna technologies was a bit tedious. Perhaps these companies are on the forefront of Java transactions (possible); perhaps the authors are most familiar with the products of these companies (looking at the biographies, this is likely). The warnings-find out who is writing the transaction software, which is probably at the heart of your business, and how often they've written such software before-were useful, if a bit repetitive.

That said, this book was still a good read, if a bit long (~360 pages). I think that Java Transaction Processing would be especially useful for an enterprise architect looking to leverage existing (expensive) transactional systems with more modern technology, and trying to see how Java and its myriad APIs fit into the mix. (This is what I imagine, because I'm not an enterprise architect.) I also think this book would be useful to DBAs; knowing about the Java APIs and how they deal with transactions would definitely help a DBA discuss software issues with a typical Java developer.

To me, an average Java developer, the first section of the book was the most useful. While transactions are fairly simple to explain (consider the canonical bank account example), this section illuminated complexities I'd not even thought of-optimizations, heuristic outcomes, failure recovery. These issues occur even in fairly simple setups-I'm working at a client who wants to update two databases with different views of the same information, but make sure that both are updated or neither; this seems to be a typical distributed transaction. The easiest way to deal with this is to pretend that such updates will always be successful, and then accept small discrepancies. That's fine with click-throughs-money is a different matter.

However, if you are a typical web developer, I'm not sure this book is worth the price. I would borrow it from your company's enterprise architect, as reading it will make you a better programmer (as well as giving you a sense of history-transactions have been around for a long time). But, after digesting fundamental distributed transaction concepts, I won't be referencing this book anytime soon, since the scenarios simply don't happen that often (and when they do, they're often ignored, as outlined above).

This is not a book for beginners. It assumes knowledge of Java and as well as a fairly broad knowledge of various other technologies. However, I did find it to be quite readable considering its complex subject matter, with an excellent balance between theory, practice, and illustrative examples. Many J2EE application developers do not understand two phase commit transactions, and hence have little understanding of, for example, the consequences of involving messaging and database operations in the one transction. I would highly recommend this book to all J2EE developers as an excellent way to address this ignorance, and as an eye opener to the possibilities of alternative transaction models.

Much of the book is devoted to two phase commit transactions:

- How they are implemented. Almost enough information to implement one yourself (though they strongly recommend against trying!)

- The Object Transaction Service Architecture on which the Java Transaction API is based: this section has considerable detail made surprisingly readable by numerous sequence diagrams.

- Heuristic Decisions: detailing the meanings of the different heuristic outcomes, such as heurist-rollback, heuristic-commit, heuristic-mixed, and heuristic-hazard.

- Optimizations: presumed-abort; one-phase; read-only; and last-resource-commit.

- The implications for database access and messaging (JMS), and information on the approaches taken by different vendors.

- The implications for EJB and other J2EE programming.

- Optimistic vs pessimistic locking schemes, commit options, isolation levels, and transaction context propagation.

- The J2EE Connector Architecture (JCA): its API's and what's involved in creating a resource adaptor.

Other topics are covered in considerable depth, including:

- The J2EE Activity Service as a framework for supporting alternative transaction models to the standard ACID model. For example, it lets you define a transaction in terms of a sequence of actions and any required compensation actions required upon failures.

- Transactions & Web Services: describing a number of different specificiations that have been defined and implemented for supporting distributed transactions over web services.

"Java Transaction Processing" provides a clear-cut, understandable journey through the nether-world of transaction processing. This information is critical to the development of robust applications and Mr's Little, Maron, and Pavlick have brigdged the gap between the "standard-speak" of XOPEN and the vagueness of the JTA specifications. Highly recommended.