Pivotal Knowledge Base


Avoid reading a mix of pre and post transaction data

Applies to

GemFire 7 and 8


Describe how to avoid working with a mix of pre and post transaction data in another thread.


When you commit a transaction, while the commit is taking place, the changes are visible in the distributed cache. This provides better performance than locking everything involved with the transaction updates, but it means that another process accessing data used in the transaction might get some data in the pre-transaction state and some in the post-transaction state.

For example, suppose key 1 and 2 are written to in a transaction so both of their values change from A to B. In another thread, it is possible to read key 1 with value B and key 2 with value A, while the transaction is being committed. This is possible due to the nature of GemFire reads. This choice sacrifices atomic visibility in favor of performance; reads do not block writes, and writes do not block reads.


It is possible to be aware of this happening by doing the reads in the second thread inside of a transaction as well. For this to work it is necessary to set the GemFire property gemfire.detectReadConflicts to true. Then when doing the read inside of a transaction a conflict will happen at commit time if a partial transaction state were read during the transaction.

public static void main(String[] args) throws Exception {
System.setProperty("gemfire.detectReadConflicts", "true");
Properties cprops = new Properties();
Cache cache = new CacheFactory(cprops).set("cache-xml-file", "etc/cache.xml").create();


Powered by Zendesk