How Client Transactions Work
The syntax for writing client transactions is the same as with server or peer transactions, but when a client performs a transaction, the transaction is delegated to a server that brokers the transaction.
The client can run transactions on the Java cache server, using a server delegate to actually run the transaction code.
For information on transaction requirements and activities on the server side, see the server documentation at Transactions.
Note: The client cache blocks until the transaction is successfully committed. However, the block is removed if the transaction is suspended.
Depending on where the data resides, the server transaction delegate may or not be the same member that hosts the transaction. This is the same as for transactions run by the servers, but for server-run transactions, there is no delegate. There is just the member that is directly running its own transaction code.
In this figure, the application code on the client makes changes to data entries Y and Z within a transaction. The server delegate that performs the transaction, M1, does not host the primary copy of the data being modified. The transaction takes place on server M2, where the data resides.
To maintain cache consistency, the local client cache is not accessible during a transaction as it may reflect information inconsistent with the transaction in progress. When the transaction completes, the local cache is accessible again.
In addition to the failure conditions common to all transactions, client transactions can also fail if the transaction delegate fails. If the delegate performing the transaction fails, the transaction code throws a
The API for distributed transactions has the familiar relational database methods,
rollback. There are also APIs available to suspend and resume transactions.
The .NET classes for executing transactions are: