docs/geode-native-docs/transactions/running-client-xact.html.md.erb

---
title:  Running a Transaction
---

<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->

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.

1.  Retrieve the transaction manager.

    **C++ example**

    ``` pre
    std::shared_ptr<CacheTransactionManager> txManager =
        cache->getTransactionManager();
    ```

    **C\# .NET example**

    ``` pre
    CacheTransactionManager txManager =
          cache.CacheTransactionManager;
    ```

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

    **C++ example**

    ``` pre
    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
      tid = txManager->commit();
    }  catch (const CommitConflictException& e) {
      // ..on exception 
    }
    ```

    **C\# .NET example**

    ``` pre
    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.

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, 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 <%=vars.product_name%> 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.