CacheLoader & Isolation Levels

[tallpsmith]

This relates to my other post "SERIALIZABLE Bug? Read of null, put, another thread reading", and I just wish to clarify something.

Assuming a rather simplistic TreeCache usage, where all Fqn would be of the form "/23" where the number is really the ID of the object row in the DB.

If I implement a CacheLoader that can implement the "get(Fqn)"method to return the object from the DB store, will the TreeCache already "serialize" access to this cache ID regardless of the current Isolation Level?

I don't really need true "Serializable" access, but I only need something that will block threads trying to read the object mapped to this Fqn while one thread is gathering it from the DB store.

If this is the case, then I assume I don't need to really worry about Isolation Levels.

[tallpsmith]

answering my own question I think, but from doing some test cases, it appears I still need the SERIALIZABLE isolation level in the above example using a CacheLoader, as 2 threads trying to read the same (empty/null) value will both go "hunting" in the db and clobber the first ones value.

Testing also shows that if I stick with a Fqn schema of a top level "/[SomeID]" pattern, the lock granularity is still fine enough that it does not prevent reads of other ID's while another thread is retrieving the value for some other ID.

Any thoughts on this? Am I incorrect?

[belaban]

The answer is "yes" you need it for the current version (1.1) b/c the cache loading is not synchronized between threads. However, in CVS head (becoming JBossCache 1.2 before the end of the year, hopefully by mid December), this *is* synchronized, so you should be fine.
This is orthogonal from the isolation level.

Bela