More information regarding my issue:
(+) The unexpected results happens even when configured as SERIALIZABLE.
(+) I am using jbosscache 1.3.0 so the following issue should have been fixed: http://jira.jboss.com/jira/browse/JBCACHE-285
Would http://jira.jboss.com/jira/browse/JBCACHE-407 apply to your problem?
Hi manik, thanks for your quick reply,
I dont think it is direcly related to my problem as i am not doing any rollback in my testcase. Also, I dont have a problem with nodes but with keys ( which i believe is a different case in rollback anyway).
My issue is a really a basic classic scenario of a reader/write with READ_COMMITED/SERIALIZEABLE isolation level: I dont expect the reader to know of the values before the writer commits.
I believe the issue is solved - but its only from my 1st impression (which is enough for me for the moment)
There are multiple ways to read the content of the cache and some dont support the isolation levels.
If you use cacheInstance.printDetails() you would get all the cache content - commited and uncommited. Of course you should use cacheInstance.get(...) methods that seems to support the isolation levels.
I think it should be well documented that printDetails (and maybe other methods - even "debugging" methods) does not support the isolation levels.
take care all.