|Using Distributed Transactions in Your Applications / Overview of GemFire XD Distributed Transactions|
GemFire XD supports several transaction isolation levels. It does not support the SERIALIZABLE isolation level, nested transactions, or savepoints.
GemFire XD applies read and write locks to copies of selected data to ensure repeatable reads for the duration of a transaction. GemFire XD does not use range locks, and phantom reads are still possible with this isolation level.
In addition, readers that use the REPEATABLE_READ isolation level are guaranteed to see distributed, atomic commits. This means that if there is a transaction that writes rows and commits over multiple GemFire XD members, then readers either see all of the commit row values across all members of the distributed system (after the commit), or they will see all of before-committed row values across all members. Readers never see some committed rows on one member and before-committed row values on another node (as with READ_COMMITTED transaction isolation). To support this behavior, GemFire XD uses a 2-phase commit protocol for all REPEATABLE_READ transactions that have pending writes. Note that using REAPEATABLE_READ isolation has higher chance of receiving deadlocks because there are much greater overlaps between readers and writers. Deadlocks cause one or both transactions to fail after a timeout period (see gemfire.LOCK_MAX_TIMEOUT).
GemFire XD detects conflicts between two transactions that write on the same row either during the transactions or just before a commit for READ_COMMITTED and REPEATABLE_READ transactions. However, if a REPEATABLE_READ transaction writes on the same row that has been read by another transaction, then GemFire XD always detects such a conflict before the writer commits (in the first phase of the commit). This enables the system to minimize conflicts where reader transactions are short in duration and the transactions complete before the writer starts its commit.
Applications should avoid mixing REPEATABLE_READ and READ_COMMITTED transactions to reduce potential conflicts. If a REPEATABLE_READ transaction is started before a READ_COMMITTED transaction, the REPEATABLE_READ transaction can potentially hold read locks, resulting in a conflict exception with the READ_COMMITTED transaction.
GemFire XD provides the gemfire.LOCK_MAX_TIMEOUT system property that you can use to alter the conflict detection behavior for READ_COMMITTED and REPEATABLE_READ transactions.