Running a Transaction

Before you can run a transaction, you must configure your clients and servers, define your server regions for your transactions, and define your client regions.

Retrieve the transaction manager.

C++ example

CacheTransactionManagerPtr txManager = 
      cache->getCacheTransactionManager();

C# .NET example

CacheTransactionManager txManager =
      cache.CacheTransactionManager;

Run the transaction. (Detailed steps follow the examples.)

C++ example
```
TransactionIdPtr tid;
txManager->begin();
// ..do work
tid = txManager->suspend();
// following code can be run from another
// thread that has access to tid
try {
  txManager->resume(tid);
  // ..do work
  tid = txManager->commit();
}  catch (const CommitConflictException& e) {
  // ..on exception 
}
```
C# .NET example
```
TransactionId tid;
txManager.Begin();
// ..do work
tid = txManager.Suspend();
// following code can be run from another
// thread that has access to tid
try {
  txManager.Resume(tid);
  // ..do work
  txManager.Commit();
} catch (CommitConflictException e)
```
- Start each transaction with a begin operation.
- If the transaction runs on server regions that are a mix of partitioned and replicated regions, perform the first transaction operation on a partitioned region. This sets the server data host for the entire transaction. If you are using PR single-hop, single-hop will be applied as usual to this first operation.
- Run the operations that you want included in the transaction.
- End the transaction with a commit or a rollback. Note: Do not leave any transaction in an uncommitted and unrolled back state unless you have suspended the transaction. Transactions that have not been explicitly suspended do not time out, so will remain in the system for the life of your application.
Review all of your client code for compatibility with transactions.

When you commit a transaction, while the commit is taking place, the changes are visible in the cache. This is also known as transition commits. This provides better performance than locking everything to do the transaction updates, but it means that another process accessing data used in the transaction might get some data in the pre-transaction state and some in the post-transaction state.

For example, keys 1 and 2 are written to in a transaction so both of their values change from A to B. In another thread, it is possible to read key 1 with value B and key 2 with value A, while the transaction is being committed. This can happen because of how GemFire performs reads. This choice sacrifices atomic visibility in favor of performance. Reads do not block writes. Writes do not block reads.

Because the client cache waits during transaction execution, and client regions are not distributed, the only activities that interact with a client transaction are those that occur on the server.