[chtimi2]

Wrt the behaivour when writeSkewCheck is false, could you please enhance your test so that you can assert it in such way that it fails under this condition?

The test already fails "under this condition", that is when the writes are not thread safe:

@Test
public void isolation_RW_RW () throws Exception
{
 table.initScalar ();

 int nbWriters = 10;
 CountDownLatch latch = new CountDownLatch ( nbWriters );

 for ( int i = 0 ; i < nbWriters ; i ++ )
 {
 executorService.submit ( new AsyncIncrement ( latch ) );
 }
 latch.await ();
 assertEquals ( nbWriters , table.getScalar() );//That's the line that fails when writes are not thread-safe
}

Or do you mean something else?

[chtimi2]

Alright i tried the better test you provided, and the behaviour is exactly the same:
-with READ_COMMITTED: test passes
-with REPEATABLE_READ, writeSkewCheck=false: test assertion fails (expected 10, got [anything between 2 and 7])
-with REPEATABLE_READ, writeSkewCheck=true: still the same exception
but unlike you who gets it randomly, i get it every single time

[chtimi2]

So you use Future.get on all tasks to get exceptions to the launching thread, i didn't know that. That's nice.

[galder.zamarreno]

Hey, I managed to have a look at the situation when writeSkew is false and I suspect it's exactly the same issue as explained JBCACHE-1555. Threads are peeking and then asking for the lock, so by the time they acquired the lock, they contain stale data and they're working of that. As a result, you see updates not being propagated to these threads.

[galder.zamarreno]

This should be fixed in JBoss Cache 3.2.2