Overview

Transactions are a fundamental tool for many kinds of computing. A transaction allows a set of operations to be grouped in such a way that they either all succeed or all fail; further, the operations in the set appear from outside the transaction to occur simultaneously. Transactional behaviors are especially important in distributed computing, where they provide a means for enforcing consistency over a set of operations on one or more remote participants. If all the participants are members of a transaction, one response to a remote failure is to abort the transaction, thereby ensuring that no partial results are written.

Traditional transaction systems often center around transaction processing monitors that ensure that the correct implementation of transactional semantics is provided by all of the participants in a transaction. Our approach to transactional semantics is somewhat different. Within our system we leave it to the individual objects that take part in a transaction to implement the transactional semantics in the way that is best for that kind of object. What the system primarily provides is the coordination mechanism that those objects can use to communicate the information necessary for the set of objects to agree on the transaction. The goal of this system is to provide the minimal set of protocols and interfaces that allow objects to implement transaction semantics rather than the maximal set of interfaces, protocols, and policies that ensure the correctness of any possible transaction semantics. So the completion protocol is separate from the semantics of particular transactions.

The two-phase commit protocol is designed to enable objects to provide ACID properties. The default transaction semantics define one way to preserve these properties.
The ACID properties are:

• Atomicity – all the operations grouped under a transaction occur or none of them do. The protocol allows participants to discover which of these alternatives is expected by the other participants in the protocol. However, it is up to the individual object to determine whether it wishes to operate in concert with the other participants.
• Consistency – the completion of a transaction must leave the system in a consistent state. Consistency includes issues known only to humans, such as that an employee should always have a manager. The enforcement of consistency is outside of the realm of the transaction itself – a transaction is a tool to allow consistency guarantees and not itself a guarantor of consistency.
• Isolation – ongoing transactions should not affect each other. Participants in a transaction should see only intermediate states resulting from the operations of their own transaction, not the intermediate states of other transactions. The protocol allows participating objects to know what operations are being done within the scope of a transaction. However, it is up to the individual object to determine if such operations are to be reflected only within the scope of the transaction or can be seen by others who are not participating in the transaction.
• Durability – the results of a transaction should be as persistent as the entity on which the transaction commits. However, such guarantees are up to the implementation of the object.

When using transactions, the following happens:

• The client application contacts the transaction manager in order to create a new transaction (remote call).
• An object containing a transaction and a lease is returned from the transaction manager.
• The client application performs several operations in the context of the transaction, passing the transaction object as an argument to each operation.
• When the first operation, performed in the context of the transaction, arrives at the space, it forces the space to "join" the transaction. This involves a remote call from the space to the transaction manager.
• The client commits the transaction. This involves a remote call to the transaction manager.
• The transaction manager begins a 2PC (Two-Phase Commit) process. In the first phase, the transaction manager contacts each of the participants in the transaction and issues a "prepare" command (remote call).
• If every participant succeeds in the prepare phase, then the transaction manager proceeds to the second phase, in which it issues a commit command to the transaction participants (remote call). If at least one of the participants failed to prepare, the transaction is rolled back.
• The transaction manager maintains the transaction state on the disk or in memory. The client thread is unblocked, and it can continue to start a new transaction.

When using transactions you should:

• Get the Transaction Manager.
• Get the transaction object from the Transaction Manger using the net.jini.core.transaction.TransactionFactory.
• Use the transaction object as part of the operation.
• Commit or abort the transaction using the transaction object.

  The Transaction.Created object returned by the Transaction Manager contains a lease object as well as the transaction itself, both for local and distributed transactions. The lease object allows you to renew and manage the lease of the transaction.

  For more details on transaction usage, refer to: http://java.sun.com/products/jini/2.0/doc/specs/html/txn-spec.html

When a transaction is timed out, its locked Entries are released when the lease manager thread is triggered. This means that if a client fails while a transaction is opened with locked Entries (take, write, read, and update using transactions), the locked Entries are released once the lease manager thread identifies the expired transaction.

More in this Section

You can perform any operation with the space under transaction. GigaSpaces supports the following Transaction Managers:

• Jini Transaction Manager
• Local Transaction Manager
• XA Transaction Support