This topic explains transactions in Native Client for VMware GemFire.
The Native Client API runs transactions on the server as if they were local to the client application. Thus, the key to running client transactions lies in making sure the server is properly configured and programmed. For complete information about how transactions are conducted on the GemFire server, see the Transactions section of the GemFire User Guide.
The API for distributed transactions has the familiar relational database methods, Begin
, Commit
, and Rollback
. There are also APIs available to suspend and resume transactions.
The .NET Framework classes for executing transactions are:
Apache.Geode.Client.CacheTransactionManager
Apache.Geode.Client.TransactionId
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.
Start each transaction with a Begin
operation, and end the transaction with a Commit
or a Rollback
.
To maintain cache consistency, the local client cache is not used during a transaction. When the transaction completes or is suspended, local cache usage is reinstated.
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.
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 TransactionException
.
The native client release contains a transaction example in ../examples/dotnet/transaction
.
The example performs a sequence of operations, displaying simple log entries as they run.
README.md
file in the example directory.Review the source code in the example directory to see exactly how it operates.
You begin by running a script that sets up the server-side environment by invoking gfsh
commands to create a region, simply called “exampleRegion.”
You run the example client application, which performs the following steps:
put
operationsFor this example, the transaction code has these characteristics:
To introduce the possibility of failure, values are randomized from 0 to 9, and the 0 values are treated as unsuccessful. The transaction is retried until it succeeds.
In case the transaction repeatedly fails, the retry loop uses a counter to set a limit of 5 retries.
This section contains code snippets showing highlights of the .NET Framework transaction example. They are not intended for cut-and-paste execution. For the complete source, see the example source directory.
The .NET Framework example creates a cache, then uses it to create a connection pool.
var cache = new CacheFactory()
.Set("log-level", "none")
.Create();
cache.GetPoolManager()
.CreateFactory()
.AddLocator("localhost", 10334)
.Create("pool");
var regionFactory = cache.CreateRegionFactory(RegionShortcut.PROXY)
.SetPoolName("pool");
var region = regionFactory.Create<string, int>("exampleRegion");
The example application gets a transaction manager from the cache and begins a transaction.
cache.CacheTransactionManager.Begin();
Within the transaction, the client populates data store with 10 values associated with Key1 - Key10.
foreach(var key in keys)
{
var value = GetValueFromExternalSystem();
region.Put(key, value);
}
If all put
operations succeed, the application commits the transaction. Otherwise, it retries up to 5 times if necessary.
var retries = 5;
while(retries-- > 0)
{
try
{
... // PUT OPERATIONS ...
cache.CacheTransactionManager.Commit();
Console.WriteLine("Committed transaction - exiting");
break;
} catch
{
cache.CacheTransactionManager.Rollback();
Console.WriteLine("Rolled back transaction - retrying({0})", retries);
}
}