A series of
operations, either within a single service or spanning multiple services, can
be wrapped in a transaction. Specifically designed for distributed
object conversations,transaction
interfaces supply a service protocol needed to coordinate a two-phase
commit. Two-phase commit provides two steps to coordinate the actions of
a group of distributed objects. The first step is called the voting phase in
which each object “votes” whether it has completed its portion of the task
and is ready to commit any changes it made. In the second step, a coordinator
issues a commit request to each object.
The Jini
technology transaction protocol differs from most transaction interfaces in
that it does not assume that the transactions occur in a transaction
processing system.Such systems
define mechanisms and programming requirements that guarantee the correct
implementation of a particular transaction semantics. The Jini technology
transaction protocol takes a more traditional object-oriented view, leaving
the correct implementation of the desired transaction semantics up to the
implementor of the particular objects that are involved in the transaction.
The goal of the transaction protocol is to define the interactions that such
objects must have to coordinate such groups of operations.
The interfaces
that define the Jini technology programming model are used by the
infrastructure components where appropriate and by the initial Jini
technology services. For example, the Lookup Service makes use of the leasing
and event interfaces: Leasing insures that services registered
continue to be available, and events help administrators discover problems
and devices needing configuration. Leasing also supports nested
transactions.The JavaSpaces™ Service
— a Jini technology service — utilizes leasing and events, and also supports
the two-phase commit protocol. The transaction manager can be used to
coordinate the voting phase of a transaction for those objects that support
two-phase commit.