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, Geode passes the TransactionEvent to the transaction writer local to the transactional view, if one is available. After commit, Geode :

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