Monitoring and Troubleshooting Transactions

Unlike database transactions, GemFire does not write a transaction log to disk. To get the full details about committed operations, use a transaction listener to monitor the transaction events and their contained cache events for each of your transactions.

Statistics on Cache Transactions

During the operation of GemFire cache transactions, if statistics are enabled, transaction-related statistics are calculated and accessible from the CachePerfStats statistic resource. Because the transaction’s data scope is the cache, these statistics are collected on a per-cache basis.


In a failed commit, the exception lists the first conflict that caused the failure. Other conflicts can exist, but are not reported.

A transaction can create data beyond the capacity limit set in the region’s eviction attributes. The capacity limit does not take effect until commit time. Then, any required eviction action takes place as part of the commit.

Interaction with the Resource Manager

The GemFire resource manager, which controls overall heap use, either allows all transactional operations or blocks the entire transaction. If a cache reaches the critical threshold in the middle of a commit, the commit is allowed to finish before the manager starts blocking operations.

Transaction Exceptions

The following sections list possible transaction exceptions.

Exceptions Indicating Transaction Failure
  • TransactionDataNodeHasDepartedException. This exception means the transactional data host has departed unexpectedly. Clients and members that run transactions but are not the transactional data hosts can get this exception. You can avoid this by working to ensure your transactional data hosts are stable and remain running when transactions are in progress.
  • TransactionDataNotColocatedException. You will get this error if you try to run a transaction on data that is not all located in the same member. Partition your data so it is all located in a single member. See Transactions and Partitioned Regions and How Custom Partitioning and Data Co-location Work.
  • TransactionDataRebalancedException. You get this error if your transactional data is moved to another member for rebalancing during the transaction. Manage your partitioned region data to avoid rebalancing during a transaction. See Rebalancing Partitioned Region Data.
Exceptions Indicating Unknown Transaction Outcome
  • TransactionInDoubtException. Some of the transactional operations may have succeeded and some may have failed. This can happen to clients and to any member running a transaction on another data host. To manage this, you may want to install cache listeners in the members running the transaction code. Use the listeners to monitor and record the changes you receive from your transactions so you can recover as needed if you get this exception.