Monitoring and Troubleshooting Transactions
This topic covers errors that may occur when running transactions in GemFire.
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.
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.
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.
The following sections list possible transaction exceptions.
Exceptions Indicating Transaction Failure
TransactionDataNodeHasDepartedException. This exception means the transaction host has departed unexpectedly. Clients and members that run transactions but are not a transaction host can get this exception. You can avoid this by working to ensure your transaction 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 that a single member contains all data that will be accessed as part of a single transaction. See Transactions and Partitioned Regions and Understanding Custom Partitioning and Data Colocation.
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.