|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. To support this behavior, GemFire XD uses a 2-phase commit protocol for all REPEATABLE_READ transactions that have pending writes.
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.
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.