Pivotal Knowledge Base

Follow

Avoid reading a mix of pre and post transaction data

Applies to

GemFire 7 and 8

Purpose

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

Issue

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.

Solution

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();
}

Comments

Powered by Zendesk