Application Plug-Ins and Transactions

Cache Plug-Ins

All standard vFabric GemFire application plug-ins work with transactions. In addition, The transaction interface offers specialized plug-ins that support transactional operation.

Note:

No direct interaction exists between client transactions and client application plug-ins. When a client runs a transaction, GemFire calls the plug-ins that are installed on the transaction's server delegate and its server host. Client application plug-ins are not called for operations inside the transaction or for the transaction as a whole. When the transaction is committed, the changes to the server cache are sent to the client cache according to client interest registration. These events can result in calls to the client's CacheListeners, as with any other events received from the server.

The EntryEvent that the callbacks receive has a unique GemFire transaction ID, so the cache listener can associate each event, as it occurs, with a particular transaction. EntryEvents that are not part of a transaction return null instead of a transaction ID.
  • CacheLoader. When a cache loader is called by a transaction operation, values loaded by the cache loader may cause a write conflict when the transaction commits.
  • CacheWriter. During a transaction, if a cache writer exists, its methods are invoked as usual for all operations, as the operations are called in the transactions. The netWrite operation is not used. The only cache writer used is the one in the member where the transactional data resides.
  • CacheListener. The cache listener callbacks - local and remote - are triggered after the transaction commits. The system sends the conflated transaction events, in the order they were stored.

Transaction Plug-Ins

GemFire has the following transaction plug-ins:
  • TransactionWriter. When you commit a transaction, if a transaction writer is installed in the cache where the data updates were performed, it is called. The writer can do whatever work you need, including aborting the transaction.
  • TransactionListener. When the transaction ends, its thread calls the transaction listener to perform the appropriate follow-up for successful commits, failed commits, or voluntary rollbacks. The transaction that caused the listener to be called no longer exists by the time the listener code executes.

    Transaction listeners have access to the transactional view and thus are not affected by non-transactional update operations. TransactionListener methods cannot make transactional changes or cause a rollback. They can, however, start a new transaction. Multiple transactions on the same cache can cause concurrent invocation of TransactionListener methods, so implement methods that do the appropriate synchronizing of the multiple threads for thread-safe operation.

    A transaction listener can preserve the result of a transaction, perhaps to compare with other transactions, or for reference in case of a failed commit. When a commit fails and the transaction ends, the application cannot just retry the transaction, but must build up the data again. For most applications, the most efficient action is just to start a new transaction and go back through the application logic again.

    The rollback and failed commit operations are local to the member where the transactional operations are run. When a successful commit writes to a distributed or partitioned region, however, the transaction results are distributed to other members the same as other updates. The transaction listener on the receiving members reflect the changes the transaction makes in that member, not the originating member. Any exceptions thrown by the transaction listener are caught by GemFire and logged.