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.
||Transaction Processing: Concepts and Techniques
Morgan Kaufmann 1993
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,
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.