This topic has not yet been written. The content below is from the topic description.
Advanced: batching and JTA Behinds the scene, the batching functionality starts a JTA transactions, and all the invocations in that scope are associated with it. For this it uses a very simple (e.g. no recovery) TransactionManager implementation behind the scene. From this you get all sorts of nice behaviour, including: 1. Locks you acquire during an invocation are held until the transaction commits or rolls back. 2. Changes are all replicated around the cluster in a batch as part of the transaction commit process. Reduces replication chatter if multiple changes occur during the transaction. 3. If synchronous replication or invalidation are used, a failure in replication/invalidation will cause the transaction to roll back. 4. If a CacheLoader is used, and that cache loader works with a JTA resource (e.g. a JTA DataSource), the JTA resource can also participate in the transaction. 5. All the transaction related configurations apply for batching as well: Â Â Â Â Â