|Developing Applications with GemFire XD / Using Distributed Transactions in Your Applications|
For optimum results, take note of best practices for working with GemFire XD transactions.
For high performance, mimimize the duration of transactions to avoid conflicts with other concurrent transactions. If atomicity for only single row updates is required, then completely avoid using transactions because GemFire XD provides atomicity and isolation for single rows without transactions.
Unlike in traditional databases, GemFire XD transactions can fail with a conflict exception on updates instead of on commit. This choice makes sense given that the outcome of the transaction has been determined to fail.
When using transactions, keep the transaction duration and the number of rows involved in the transaction as low as possible. GemFire XD acquires locks eagerly, and long-lasting transactions increase the probability of conflicts and transaction failures.
To the extent possible, model your database so that most transactions operate on colocated data. When all transactional data is on a single member, then stricter isolation guarantees are provided.
If your application spawns multiple threads or connections to work on committed data, consider setting the sync-commits conenction property to "true." By default GemFire XD performs second-phase commit actions in the background, but ensures that the connection that issued the transaction only sees completed results. However, other threads or connections may see different results until the second-phase commit actions complete. setting sync-commits=true ensures that the current thin client or peer client connection waits until all second-phase commit actions complete.