Differences READ_COMMITTED vs REPEATABLE_READ

[zeravlai]

Hi all,

I'm testing JBoss Cache by using a JPA/Hibernate application. I'm configuring the cache with MVCC and changing the isolation from READ_COMMITTED to REPEATABLE_READ but don't see any differences. My test case is something like 2 transactions writing to the same entity bean which is stored in JBC:

1.- T1 and T2 starts and reads the EB from the cache.
2.- T1 modifies an attribute of the EB and commits. JBC and database reflects the new value.
3.- T2 re-reads the EB, which still has the values before T2 started.
4.- T2 modifies the same attribute of the EB and commits. JBC and database reflects the new value.

Is this the correct behaviour with the two isolation levels?
How the test case should be for the isolation to make a difference?

Thanks in advance.

[manik]

Hibernate has a first level cache in it's session. Which will provide you with R_R regardless of how your second level cache is configured.

[zeravlai]

Thanks for the info Manik,

so, then, given the tree structure of the cache and the R_R isolation level, would it be possible to fall into a phantom read anomaly (considering the JPA/Hibernate) ?

[zeravlai]

Also Manik, in "mvcc-entity" predefined cache config, there's a comment saying that READ_COMMITTED is as strong as neccesary for most 2nd level cache use cases. What's the meaning of this sentence bearing in mind your reply ?

Thanks again.

[manik]

"zeravlai" wrote:
Also Manik, in "mvcc-entity" predefined cache config, there's a comment saying that READ_COMMITTED is as strong as neccesary for most 2nd level cache use cases. What's the meaning of this sentence bearing in mind your reply ?

R_C is (slightly) more efficient that R_R in our MVCC implementation. This is why I recommend it for Hibernate, since Hibernate provides R_R anyway through its first level cache.