Note: is in rebuild. Please accept my apologies for broken links, missing stuff, etcetera - more

Jini building blocks - Transactions

Distributed networks need to cope with failure, and therefore most of the code should not care whether other parties are up and running or whether they just crashed. Decoupling is the magic word.

However, sometimes a number of services on the network need to coordinate something. For example, one service writes something to a log file and another one to a database - you want to be sure that either both services do their job, or neither of them. Coordination through a transaction is the standard tool in the distributed programmer's toolbox.

Jim Gray has written what is considered to be the standard work on transactions (see below). It counts a nice 1070 pages, so this is complex territory. The Jini people took the approach they have taken most of the time: when faced with very complex stuff, leave as many decisions as possible to the developer.
[Cover image - click for larger version] Transaction Processing: Concepts and Techniques
Jim Gray
Morgan Kaufmann 1993
ISBN 1-55860-190-2

To people used to heavy duty transaction processing, the Jini Transaction Specification is hopelessly incomplete (with around 30 pages of specification in the official Jini book); to people who just need to have a simple, extensible coordination mechanism, it is probably just right (or, if anything, too much).

The Jini Transaction Specification defines the absolute basics of a two-phase commit protocol: first, the transaction manager does a round of voting; only when everybody has voted to continue with the transaction, the transaction manager signals every participant to commit. A separate part of the transaction specification deals with the default semantics that are implemented in the Jini Core Package, and complying with these semantics makes sure that all the good properties of a transaction are enforced: atomicity, consistency, isolation, and durability. But the specification makes it clear that it is a separate part and that other semantics are allowed.

Jini transactions, because they are so lightweight, are extremely useful and there applicability ranges from the simplest quick-and-dirty coordination scheme to distributed database updates that need strong transactional guarantees. In the future, you'll probably see heavy-duty transaction monitors supporting Jini transactions as well (it shouldn't be too hard to implement that), which will hopefully result in a nice synergy between the "lightweight" Jini protocols and the "heavyweight" Java Transaction Architecture.

Copyright (C)2000-2011 Cees de Groot -- All rights reserved.