This section provides an explanation on how transactions work on GemFire caches.
Pivotal GemFire transactions operate on data in local member caches. All the regions in a member cache can participate in a transaction. A Java application can operate on the cache using multiple transactions. A transaction is associated with only one thread, and a thread can operate on only one transaction at a time. Child threads do not inherit existing transactions.
The diagram shows a transaction operating against a local member cache.
A transaction is isolated from changes made concurrently to the cache. Each transaction has its own private view of the cache, including the entries it has read and the changes it has made. The first time the transaction touches an entry in the cache, either to read or write, it produces a snapshot of that entry’s state in the transaction’s view. The transaction remembers the entry’s original state and uses it at commit time to discover write conflicts. The transaction maintains its current view of the entry, which reflects only the changes made within the transaction.
When a commit succeeds, the changes recorded in the transaction view are merged into the cache. If the commit fails or the transaction is rolled back, all of its changes are dropped.
If the transaction fails to complete any of the steps, a CommitConflictException is thrown to the calling application.
Once the members involved in the transaction have been asked to commit, the transaction completes even if one of the participating members were to leave the system during the commit. The transaction completes successfully so long as all remaining members are in agreement.
Each member participating in the transaction maintains a membership listener on the transaction coordinator. If the transaction coordinator goes away after issuing the final commit call, the transaction completes in the remaining members.