C.3. Transactions

The JavaSpaces API uses the package net.jini.core.transaction to provide basic atomic transactions that group multiple operations across multiple JavaSpaces services into a bundle that acts as a single atomic operation. JavaSpaces services are actors in these transactions; the client can be an actor as well, as can any remote object that implements the appropriate interfaces.

Transactions wrap together multiple operations. Either all modifications within the transactions will be applied or none will, whether the transaction spans one or more operations and/or one or more JavaSpaces services.

The transaction semantics described here conform to the default transaction semantics defined in the Jini™ Transaction Specification.

C.3.1. Operations Under Transactions

Any read, write, or take operations that have a null transaction act as if they were in a committed transaction that contained exactly that operation. For example, a take with a null transaction parameter performs as if a transaction was created, the take performed under that transaction, and then the transaction was committed. Any notify operations with a null transaction apply to write operations that are committed to the entire space.

Transactions affect operations in the following ways:

• write: An entry that is written is not visible outside its transaction until the transaction successfully commits. If the entry is taken within the transaction, the entry will never be visible outside the transaction and will not be added to the space when the transaction commits. Specifically, the entry will not generate notifications to listeners that are not registered under the writing transaction. Entries written under a transaction that aborts are discarded.

• read: A read may match any entry written under that transaction or in the entire space. A JavaSpaces service is not required to prefer matching entries written inside the transaction to those in the entire space. When read, an entry is added to the set of entries read by the provided transaction. Such an entry may be read in any other transaction to which the entry is visible, but cannot be taken in another transaction.

• take: A take matches like a read with the same template. When taken, an entry is added to the set of entries taken by the provided transaction. Such an entry may not be read or taken by any other transaction.

• notify: A notify performed under a null transaction applies to write operations that are committed to the entire space. A notify performed under a non-null transaction additionally provides notification of writes performed within that transaction. When a transaction completes, any registrations under that transaction are implicitly dropped. When a transaction commits, any entries that were written under the transaction (and not taken) will cause appropriate notifications for registrations that were made under a null transaction.

If a transaction aborts while an operation is in progress under that transaction, the operation will terminate with a TransactionException. Any statement made in this chapter about read or take apply equally to readIfExists or takeIfExists, respectively.

C.3.2. Transactions and ACID Properties

The ACID properties traditionally offered by database transactions are preserved in transactions on JavaSpaces systems. The ACID properties are:

• Atomicity: All the operations grouped under a transaction occur or none of them do.

• 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 transaction—a transaction is a tool to allow consistency guarantees, and not itself a guarantor of consistency.

• Isolation: Ongoing transactions should not affect each other. Any observer should be able to see other transactions executing in some sequential order (although different observers may see different orders).

• Durability: The results of a transaction should be as persistent as the entity on which the transaction commits.

The timeout values in read and take allow a client to trade full isolation for liveness. For example, if a read request has only one matching entry and that entry is currently locked in a take from another transaction, read would block indefinitely if the client wanted to preserve isolation. Since completing the transaction could take an indefinite amount of time, a client may choose instead to put an upper bound on how long it is willing to wait for such isolation guarantees, and instead proceed to either abort its own transaction or ask the user whether to continue or whatever else is appropriate for the client.

Persistence is not a required property of JavaSpaces technology implementations. A transient implementation that does not preserve its contents between system crashes is a proper implementation of the JavaSpace interface's contract, and may be quite useful. If you choose to perform operations on such a space, your transactions will guarantee as much durability as the JavaSpaces service allows for all its data, which is all that any transaction system can guarantee.