Geode Cache Transaction Semantics

Geode transaction semantics differ in some ways from the Atomicity-Consistency-Isolation-Durability (ACID) semantics of traditional relational databases. For performance reasons, Geode transactions do not adhere to ACID constraints by default, but can be configured for ACID support as described in this section.

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.

Geode 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. See Committing Transactions for details on the two-phase commit protocol that implements the reservation system.

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 assures that operations will see either the pre-transaction state of the system or its post-transaction state, but not the transitional state that occurs while a transaction is in progress. Write operations in a transaction are always confirmed to ensure that stale values are not written. As a distributed cache-based system optimized for performance, Geode in its default configuration does not enforce read isolation. Geode transactions support repeatable read isolation, so once the committed value is read for a given key, it always returns that same value. If a transaction write, such as put or invalidate, deletes a value for a key that has already been read, subsequent reads return the transactional reference.

In the default configuration, Geode isolates transactions at the process thread level, so while a transaction is in progress, its changes are visible only inside the thread that is running the transaction. Threads inside the same process and in other processes cannot see changes until after the commit operation begins. At this point, the changes are visible in the cache, but other threads that access the changing data might see only partial results of the transaction leading to a dirty read.

If an application requires the slower conventional isolation model (such that dirty reads of transitional states are not allowed), read operations must be encapsulated within transactions and the gemfire.detectReadConflicts parameter must be set to ‘true’:

-Dgemfire.detectReadConflicts=true

This parameter causes read operations to succeed only when they read a consistent pre- or post-transactional state. If not, a CommitConflictException is thrown to the calling application.

Durability

Relational databases provide durability by using disk storage for recovery and transaction logging. As a distributed cache-based system optimized for performance, Geode does not support on-disk or in-memory durability for transactions.

Applications can emulate the conventional disk-based durability model by setting the gemfire.ALLOW_PERSISTENT_TRANSACTIONS parameter to ‘true’.

-Dgemfire.ALLOW_PERSISTENT_TRANSACTIONS=true

This allows permanent regions to participate in transactions, thus providing disk-based durability. See Transactions and Persistent Regions for more detail on the use of this parameter.