Transactions

ActiveSpaces Enterprise Edition allows you to atomically perform sets of space operations using transactions.

Transactions can span multiple spaces, but not multiple metaspaces. A transaction starts when an individual thread in an application creates a transaction, and terminates when either commit or rollback is invoked, at which point all space operations performed by that thread are either validated or canceled. Pending transactions may be rolled back automatically when the member creating them leaves the metaspace.

Transactions can also be moved from one thread to another using the releaseTransaction() and takeTransaction() methods.

In ActiveSpaces 2.0, the only supported read isolation level is READ_COMMITTED. This isolation level applies only to your view of data modified by the transactions of other applications and threads. This means that whether in a transaction or not, you will not see uncommitted data from other transactions, but if you yourself are in a transaction you will see your own uncommitted data.

ActiveSpaces has an implied write isolation level of UNCOMMITTED, meaning that any entry potentially modified by a pending transactional operation appears to be locked for other users of the space (in which case the space’s LockWait attribute will apply).