Hi, FYI. I am trying to get a test to run on 5.3.0.a1 to confirm that DIRTY_READ intolerant transactional use cases are accommodated by the Infinispan JSR-107 API 0.4 implementation. There are 2 programs attached. The first one does not use JSR-107 at all, but rather mocks an example of a program that exhibits the trauma (inconsistent data!) of enduring a DIRTY_READ event (i.e. TX_THREAD_2 does not block @t=2). The DIRTY_READ endured in this program is cruelly coerced ... exclusively for the purpose of demonstrating the @t=X events. The second one borrows from the first program and explicitly uses the JSR-107 API 0.4 (JCACHE provider=Infinispan 5.3.0.a1) to specify its DIRTY_READ intolerance. This program has the expectation that Infinispan 5.3.0.a1 can be configured with a lockPolicy=PESSIMISTIC so that TX_THREAD_2 *blocks* @t=2). *I have not been able to get the second program to work w/ Infinispan 5.3.0.a1 as a JCACHE 0.4 provider.* Please consider helping to get the second program running, as I believe it exercise what should be a minimum expectation of what a JCACHE end-user will have for an Infinispan implementation that delivers the JSR-107 transactions option. program 1 (show what the test wants to exercise) ==> _DirtyReadIntolerantDriver.java <http://infinispan-developer-list.980875.n3.nabble.com/file/n4026949/_Dirt... program 2 (exercise the test on Infinispan 5.3.0a1's implementation of JCACHE 0.4 API) ==> DirtyReadIntolerantDriver.java <http://infinispan-developer-list.980875.n3.nabble.com/file/n4026949/Dirty... I know all of you are busy with priority devl matters, thanks for any consideration to help with this request. Ben -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/5-3-tests-to-confir... Sent from the Infinispan Developer List mailing list archive at Nabble.com.