Cache Design for Transactions

You can run transactions on any type of cache region except persistent regions and regions with global scope. A transaction attempted on these regions throws UnsupportedOperationExeption.
Note: The discussions on transactions in this guide use replicated and partitioned regions. If you use non-replicated distributed regions, follow the guidelines for replicated regions.


The most common region configurations for use with transactions are distributed replicated and partitioned:
  • Replicated regions are better suited for running transactions on small to mid-size data sets. To ensure all or nothing behavior, at commit time, distributed transactions use the global reservation system of the GemFire distributed lock service. This works well as long as the data set is reasonably small.
  • Partitioned regions are the right choice for highly-performant, scalable operations. Transactions on partitioned regions use only local locking, and only send messages to the redundant data stores at commit time. Because of this, these transactions perform much better than distributed transactions. There are no global locks, so partitioned transactions are extremely scalable as well.

Data Location

Transactions must be run on a data set hosted entirely by one member.
  • For replicated or other distributed regions, the transaction uses only the data set in the member where the transaction is run.
  • For partitioned regions, you must colocate all your transactional data in a single member.
  • For transactions run on partitioned and distributed region mixes, you must colocate the partitioned region data and make sure the distributed region data is available in any member hosting the partitioned region data.

For transactions involving partitioned regions, any member with the regions defined can run the transactional application, regardless of whether the member hosts data for the regions. If the transactional data resides on a remote member, the transaction is carried out by proxy in the member hosting the data. The member hosting the data is referred to as the transactional data host.

Transactions and Functions

You can run a function inside a transaction and you can run a transaction inside a function, as long as your combination of functions and transactions does not result in nested transactions. You cannot call a function from inside a transaction if the function runs its own transaction.

You can also have multiple functions participate within a single transaction.

If you are suspending and resuming a transaction with multiple function calls, all function calls participating in the transaction must execute on the same member.