How Transaction Events Are Managed
Transactional cache operations are handled somewhat differently inside transactions than out.
During the Transaction
While the transaction is running, each transactional operation is passed to the cache writer local to the transactional view, if one is available. As with cache operations outside of transactions, the cache writer can abort the operation. Each operation the cache writer allows is applied to the transactional view in the cache and appended to the CacheEvent list in the TransactionEvent object.
The cache events are conflated, so if a key already has an event in the list, that event is removed and the current operation is added to the end of the list. So this series of calls inside a transaction:
Region.create (A, W); Region.put (A, valX); Region.put (B, valQ); Region.invalidate (A); Region.put (A, valY);
results in these events stored in the CacheEvent list:
put (B, valQ) put (A, valY)
At commit and after commit
When the transaction is committed, GemFire passes the
TransactionEvent to the transaction writer local to the transactional view, if one is available. After commit, GemFire :
- Passes the
TransactionEvent to each installed transaction listener.
- Walks the
CacheEvent list, calling all locally installed listeners for each operation listed.
- Distributes the
TransactionEvent to all interested caches.
For GemFire and global JTA transactions, the
EntryEvent object contains the GemFire transaction ID. JTA transaction events do not contain the JTA transaction ID.