Overview

The transactional operation enables distributed transactions – i.e. performing a series of operations on several distributed transactional resources in a single logical transaction. However, if the transaction occurs on a single space, the overhead is relatively expensive. Although the transaction manager knows at the beginning of the 2PC process that only one transaction participant exists in the transaction, and it shortcuts the process by issuing a prepareAndCommit command (in a single remote call), there are still several remote calls that can be skipped:

• The remote call from the client to the transaction manager when a new transaction is created.
• The remote call from the space to the transaction manager to join the transaction.
• The remote call from the client to the transaction manager to commit the transaction.

These three remote calls are completely eliminated when performing local transactions. However, local transactions are limited to work with a single space. Such optimization is necessary because in many applications, a large number of transactions are performed using a single space.

When a client interacts with a clustered space that is using hash-based load-balancing (i.e. a partitioned space), and performs transactional operations using the Local Transaction Manager; routing all operations under the transaction to the same partition (i.e. routing field hash code matches the same partition) does not result in an error message – the transaction is successfully committed. A Jini transaction must be used when the transaction involves operations that are routed to multiple partitions. Since the local transaction is faster than the Jini transaction, you can optimize your application's performance by routing all transactional operations to the same partition using the Local Transaction Manager.

Using local transactions is easy; instead of searching for a transaction service, the client application simply instantiates a local transaction manager:

import com.j_spaces.core.client.LocalTransactionManager;

...

// create a local transaction manager
  TransactionManager trManager = LocalTransactionManager.getInstance((IJSpace) space);

// create a transaction
  Transaction.Created tCreated = TransactionFactory.create(trManager, 3600 * 1000);
  Transaction tr = tCreated.transaction;

// using the transaction
  space.write(..., tr, ...);

// committing the transaction
  tr.commit();

The Transaction.Created object 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.

The Local Transaction Manager is a lightweight object inside the client application. It is not a remote object. When you instantiate the Local Transaction Manager, you pass it as a reference to the space proxy. This associates the Transaction Manager with the space. No remote calls are involved in this stage. In order to prevent multiple instances of LocalTransactionManager per space, we use a single tone method, getInstance(). Each subsequent call returns one and only one instance per space.

After creating a Local Transaction Manager, you can use it as the Jini Transaction Manager. Use the Jini Transaction Factory to create a transaction and pass it to the transaction manager. Since the transaction manager is local, no remote calls are involved in this stage. You get back a transaction object, usable in subsequent calls to the space.

Finally, commit the transaction. This involves only one remote call to the space (but not to the transaction manager). If the space is running in embedded mode, this call is not remote.

Thus, three remote calls on Jini Transactions are eliminated.

Local transactions are limited to work with a single space or with a replication or failover policy based cluster. For partitioned space using load-balancing with hash-based policy make sure you use the Jini Transaction Manager.

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.