Jini Technology's Distributed Transaction Model
The Jini technology distributed transaction model is designed to enable the coordination of multiple distributed operations, such that they all succeed or they all fail. Using the model, transaction participants coordinate their efforts through a transaction manager, which is responsible for managing the two-phase commit protocol across transaction participants.
To begin a transaction, a transaction initiator requests the transaction manager to create a new transaction. The transaction manager leases the resources it uses on behalf of the transaction to the initiator, which is responsible for keeping the transaction alive (by renewing the lease) until the work of all transaction participants has been initiated.
The transaction manager provides the initiator with a transaction object, through which transaction participants can interact with the transaction manager. This object is then passed to each participant as part of the transaction initiator's request that the participant do work under the transaction. Participants first use the transaction object to register themselves with the transaction manager as participants in a particular transaction, and then they perform their transaction work.
Once the initiator has contacted all transaction participants, it uses the transaction object to tell the transaction manager the transaction is ready to be committed. The transaction manager then collects readiness votes from all participants that have registered with the transaction, issues commit or rollback instructions to them as appropriate, and notifies the initiator of the transaction's successful completion or its failure.
In this transaction-processing model, voting cannot take place, and hence the transaction cannot complete, before the initiator tells the transaction manager that all participants have been successfully engaged. This is why transactions are leased: if the initiator fails before contacting all participants, the transaction's lease will also expire before the transaction manager has been asked to complete the transaction. The expired lease signals the transaction manager to abort the open transaction.
Because lease durations can vary, and because input from the transaction initiator can be used to establish the duration of a transaction's lease, you may improve the efficiency of transaction failure detection by using leasing. This is especially true if the time generally needed to complete transactions varies greatly from one kind of transaction to another. For example, you can detect failures more rapidly by using shorter lease durations for transactions that generally require less time to complete and longer lease durations to process transactions that generally take longer to complete, reducing the number of renewals that you need to keep them alive.
Jini Technology's Distributed Event Model
The Jini technology distributed event model allows one distributed component to register interest in and receive notifications of events generated by another component. Again, the basic model is straightforward yet powerful, and specifically designed to operate well in dynamic, distributed environments.
In its simplest form, an object that wants to be notified of an event's occurrence registers its interest in the event with the event generator, using some interface that the generator exposes to allow such registration. The event notification registration is leased, which means that the event generator will maintain the notification registration on behalf of the notification receiver and send event notifications to the receiver for as long as the receiver continues to renew the lease. If a partial failure prevents the event receiver from being able to renew the lease, the event generator will remove the event notification registration and discontinue notifications.
The Jini technology distributed event model also allows an object to specify that event notifications be sent to a third party, rather than directly back to the object that registered interest in the event. This powerful feature enables you to process event notifications in any number of ways that may best meet the needs of the object that is (or objects that are) ultimately interested in the events. For example, an object might request that event notifications for multiple events be sent to a filter, so that the filter will pass through notifications only when a complete series of events has transpired. Alternatively, events might be held for batch retrieval.
The Jini technology distributed event model also acknowledges that properly ordering the sequence of remote events can be a challenge in distributed computing. The basic problem is that, given the unpredictable and inconsistent network latencies that characterize distributed computing environments, notification of an event that was actually generated before another event may nonetheless arrive after notification of the later event. Precise synchronization of all clocks in a distributed system generally is not possible. So time stamping cannot necessarily resolve this problem.
Furthermore, this ordering problem is compounded if the events were not generated by the same source. This situation proves logically impossible to resolve (or so they tell me, without breaking the space-time continuum in some strange way that would enable time to be viewed identically from all frames of reference. Wow, let's not go there!). The problem of tracking the sequence of events generated by a single source is tractable however, and the Jini technology distributed event model resolves it simply by enabling the attachment of sequence numbers to events.
Distribution also introduces the problem of unreliable event delivery: it is impossible to guarantee that a network will not fail and, therefore, impossible to guarantee that event notifications will be reliably received. That said, an event generator can implement any number of re-try strategies to make a best effort to deliver event notifications. You can implement these strategies within objects that use the Jini technology distributed event model, but they are not explicitly defined as part of the model.