This section introduces Tanzu GemFire transactions. Tanzu GemFire offers an API for client applications that do transactional work. Tanzu GemFire implements optimistic transactions, choosing the much higher transaction performance they offer over the slow, locking methods of a traditional relational database.
Optimistic transaction semantics are not identical to the Atomicity-Consistency-Isolation-Durability (ACID) semantics of a traditional relational database.
Atomicity
Atomicity is “all or nothing” behavior: a transaction completes successfully only when all of the operations it contains complete successfully. If problems occur during a transaction, perhaps due to other transactions with overlapping changes, the transaction cannot successfully complete until the problems are resolved.
Optimistic transactions provide atomicity and realize speed by using a reservation system, instead of using the traditional relational database technique of a two-phase locking of rows. The reservation prevents other, intersecting transactions from completing, allowing the commit to check for conflicts and to reserve resources in an all-or-nothing fashion prior to making changes to the data. After all changes have been made, locally and remotely, the reservation is released. With the reservation system, an intersecting transaction is simply discarded. The serialization of obtaining locks is avoided.
Consistency
Consistency requires that data written within a transaction must observe the key and value constraints established for the affected region. Note that validity of the transaction is the responsibility of the application.
Isolation
Isolation is the level at which transactional state is visible to system components. Tanzu GemFire transactions have repeatable read isolation. Once the committed value is read for a given key, it always returns that same value. If a write within a transaction deletes a value for a key that has already been read, subsequent reads return the transactional reference.
The default configuration isolates transactions at the process thread level. While a transaction is in progress, its changes are visible only inside the thread that is running the transaction. Other threads within that same process and threads in other processes cannot see changes until after the commit operation begins. After beginning the commit, the changes are visible in the cache, but other threads that access the changing data might see partial results of the transaction, leading to a dirty read. See Changing the Handling of Dirty Reads for how to change the default behavior.
Durability
Relational databases provide durability by using disk storage for recovery and transaction logging. Tanzu GemFire is optimized for performance and does not support on-disk durability for transactions.
See Allowing Transactions to Work on Persistent Regions for how to allow a transaction that operates on a persistent region in a non-durable way.
