|Developing Applications with GemFire XD / Using Distributed Transactions in Your Applications|
GemFire XD implements optimistic transactions. The transaction model is highly optimized for colocated data, where all of the rows updated by a transaction are owned by a single member.
GemFire XD avoids the use of a centralized distributed lock manager and the traditional 2-phase commit protocol. Transactional state is managed on each data store that is affected by the transaction, using only local locks. This allows the cluster to scale even when applications utilize transactions.
When 2-phase commit is used, GemFire XD performs second-phase commit actions in the background, but ensures that the connection that initiated the transaction sees only the committed results. You can change this default behavior using the sync-commits property.
Acquire eager locks. Each transactional write operation is propagated to all replicas in parallel, where a local transaction coordinator acquires a LOCAL write lock on the key.
Fail fast. If a write lock cannot be acquired (presumably due to a concurrent, conflicting transaction) then the write backs off and marks the transaction for rollback. The transaction outcome cannot be reversed.
The typical transaction duration is short.
Conflicts between transactions are rare. If concurrent transactions tend to conflict, it is the application's responsibility to retry the failed transaction.
Using this design provides the potential for linear scaling, and improves transaction performance as compared to systems that use a centralized lock manager. Without centralized lock management, transaction throughput can easily scale with additional members. Transaction processing involves the data stores plus a coordinating peer. If the concurrent transaction workload is uniformly spread across the data set, then increasing the number of data stores also balances the workload and increases the aggregate transaction throughput. The design also removes the colocation restriction for the transactional working set, because transactions can involve any number of data stores.