Transactions are best defined using the tried-and-true ACID characteristics, which are familiar to database researchers. ACID refers to units of work that are:
Any and all actions carried out as part of the transaction are committed when the transaction is committed or undone/cancelled if the transaction is cancelled (rolled back).
The actions within a transaction produce results that are consistent.
Transactions do not see each other's effects until they are committed. If a transaction is rolled back, its effects are not seen by other contexts.
If a transaction completes successfully, its effects are made permanent.
The Transaction Service defines interfaces that allow distributed objects to create and engage in transactional interactions. A transactional interaction can involve a series of remote method calls. If a significant error is encountered along the way, the transaction can be rolled back, and the effects of all previous method calls are undone, as if the transaction never started in the first place. When a transactional client starts a transaction and then makes remote method calls, its transaction context is propagated along with the requests. Only transactional objects (i.e., objects whose internal actions and side effects should be undone by a rollback of the transaction and who participate in the Transaction Service protocol) heed the transaction context information.
An important item to note about the Transaction Service, and about transaction APIs in general, is that they principally provide a framework for the notification and management of transaction boundaries, but no facilities to ease the rollback of transactions. The application objects still need to do the hard work of undoing any work that was done during a transaction if it gets rolled back. In other words, the Transaction Service tells you when to do it, but not how.
Transactions are usually managed using the Current interface, which starts and ends transactions. Transactions can be directly manipulated using the Control interface, which contains a Terminator that ends the transaction with either a commit or rollback, and a Coordinator that checks for relationships between transactions. Resource objects can be registered as participating in transactions, which allows them to be notified of transaction boundaries (commit, rollback).
The Transaction Service depends on both the Concurrency Control Service, for its locking services, and the Persistent Object Service, to support the durability (persistence) of transaction effects on objects.
 |  |  |
| 11.8. Relationship Service |  | 11.10. Query Service |
Copyright © 2001 O'Reilly & Associates. All rights reserved.
| This HTML Help has been published using the chm2web software. |