anchor.diff:  **Note:**
   You can also use transaction plug-in event handlers when running JTA global transactions.
   
  -## TransactionWriter
  +### 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.
   
  
positive.code: cTxMgr.commit();
  ```
  
  ## Transactions and Functions
  
  You can run a function from inside a transaction and you can nest a transaction within a function, as long as your combination of functions and transactions does not result in nested transactions. See [Function Execution](../function_exec/chapter_overview.html) for more about functions.
  
  A single transaction may contain multiple functions.
  
  If you are suspending and resuming a transaction with multiple function calls, all functions in the transaction must execute on the same member.
  
  See [Transaction Embedded within a Function Example](transactional_function_example.html#concept_22331B3DBFAB4C0BA95EF103BFB71257) for an example.
  
  ## Using Queries and Indexes with Transactions
  
  Queries and indexes reflect the cache contents and ignore the changes made by ongoing transactions. If you do a query from inside a transaction, the query does not reflect the changes made inside that transaction.
  
  ## Collections and Region.Entry Instances in Transactions
  
  Collections and region entries used in a transaction must be created inside the transaction. After the transaction has completed, the application can no longer use any region entry or collection or associated iterator created within the transaction. An attempted use outside of the transaction will throw an `IllegalStateException` exception.
  
  Region collection operations include `Region.keySet`, `Region.entrySet`, and `Region.values`. You can create instances of `Region.Entry` through the `Region.getEntry` operation or by looking at the contents of the result returned by a `Region.entrySet` operation.
  
  ## Using Eviction and Expiration Operations
  
  Entry expiration and LRU eviction affect the committed state. They are not part of a transaction, and therefore they cannot be rolled back.
  
  ## About Eviction
  
  LRU eviction operations do not cause write conflicts with existing transactions, despite destroying or invalidating entries. LRU eviction is deferred on entries modified by the transaction until the commit completes. Because anything touched by the transaction has had its LRU clock reset, eviction of those entries is not likely to happen immediately after the commit.
  
  When a transaction commits its changes in a region with distributed scope, the operation can invoke eviction controllers in the remote caches, as well as in the local cache.
  
  ## Configure Expiration
  
  Local expiration actions do not cause write conflicts, but distributed expiration can cause conflicts and prevent transactions from committing in the members receiving the distributed operation.
  
  
negative.code: 
  A typical usage scenario would be to use the transaction writer to prepare the commit on the external database. Then in a transaction listener, you can apply the commit on the database.
  
  ### Transaction Listeners
  
  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.
  
  