JBossCache transaction isolation levels

[aricci]

hi all,
i am testing JBossCache (version 1.4.1.SP3) Transaction Isolation levels. For this reason i have developed a simple test application that creates 2 threads that concurrently perform local transactions. All the examples have been done with Postgres-8.2.1, and everytime i have changed JBossCache Transaction Isolation level, i have changed the corresponding one in the database.
Thread 1: looks for a bean with primary key 1 and prints it, then sleeps for 2 seconds. when it wakes up, looks again for bean with primary key 1 and prints it.
Thread 2: creates and persist a bean with primary key 1.
Everytime Thread 1 starts its execution before Thread 2.

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void doTransaction(int id) throws Exception {
 System.out.println(id + ": start transaction");

 // Thread 2
 if((id % 2) == 0) {
 em.persist(new Tx(1, 0, "adapt19"));
 System.out.println(id + ": inserted 1");
 }
 // Thread 1
 else {
 Tx tx = em.find(Tx.class, 1);
 System.out.println(id + ": " + tx);
 Thread.currentThread().sleep(2000);
 tx = em.find(Tx.class, 1);
 System.out.println(id + ": " + tx);
 }

 System.out.println(id + ": end transaction");
} catch(Exception e) {e.printStackTrace();}

Serializable: ok
Repeatable read: no

1: start tx
2: start tx
1: null
2: inserted 1
2: end tx
1: 1, 0, adapt19 [should be null]
1: end tx

Read committed: ok
Read uncommitted: no (When trying to test this Isolation level i have inserted a delay in Thread 2 to make it commit after Thraed 1)

1: start tx
1: null
2: start tx
2: inserted 1
1: null [shuold be 1, 0, adapt19]
1: end tx
2: end tx

Now my question is: is there something wrong with JBossCache Transaction Isolation levels, or something wrong with my test application?

Thank you very much
Andrea

[manik]

You should note that isolation levels aren't 100% in line with DB isolation levels. We just use the terms as analogies.

In reality, dealing with null nodes are different. For example, in your repeatable read case, try the same test with an older but value instead of a null.

It is not an excuse, it is still a limitation in our RR implementation. I've added a task to review our unit test suite around isolation levels as some scenarios are not well tested. See JBCACHE-1029

[manik]

I've added a more comprehensive set of unit tests around isolation levels, but cannot recreate the 2nd failure you talk about above (with READ_UNCOMMITTED). Perhaps the EM has another layer of caching?

See
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jboss/JBossCache/tests/functional/org/jboss/cache/transaction/isolationlevels/

Cheers,
Manik