LATEST VERSION: 9.1.1 - CHANGELOG
Pivotal GemFire® v9.1

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.

Event Conflation

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. Note: For GemFire and global JTA transactions, the EntryEvent object contains the GemFire transaction ID. JTA transaction events do not contain the JTA transaction ID.