LATEST VERSION: 8.2.7 - CHANGELOG
Pivotal GemFire® v8.2

Running a Native Client Transaction

Running a Native Client Transaction

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

For information on server and server region configuration, see the GemFire User’s Guide.

  1. Retrieve the GemFire cache transaction manager.
    C++ example
    CacheTransactionManagerPtr txManager = 
          cache->getCacheTransactionManager(); 

    C# .NET example

    CacheTransactionManager txManager =
          cache.CacheTransactionManager;
  2. Run your 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)
      }
    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 your transaction runs on server regions that are a mix of partitioned and replicated regions, perform your 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 GemFire operations and other operations that you want included in the transaction.
    • End each 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.
  3. 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, key 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 don't block writes. Writes don't 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.