Hi,

we are developing a J2EE application using Orion, replacing CMT/CMP with hibernate as persistence layer.

Im wondering witch second level cache to use. Im not sure whats the meaning of transactional in that context is.

Lets take a look at EHCache for example.
I have a transaction and change an object that I retrieved from the cache in that transaction. Before commit or rollback another thread retrieves the same object from cache. Does this thread get the original or the changed values?

If it gets the changed values, is JBoss TreeCache the only cache for hibernate that permits this?

Tanks in advance for your help.

Alex

Disclaimer: I haven't looked at the ehcache src, so I'm just speculating.

Now, if you enable debug level logging for the caching system and SQL, you will see messages in the following order (using ehcache):



If nothing else, this strongly suggests that the instance of the object in the cache is NOT the same instance that you're manipulating. Rather, what happens is that when you commit your transaction the instance in the cache is first marked invalid, then the actual db transaction takes place, and if it's successful the instance in the cache is updated by copying the properties. This, in effect, makes ehcache behave pretty much according as READ COMMITTED isolation level, which is the default isolation level for most databases.

However, I suspect that ehcache doesn't ensure that the cache updates are atomic if you use nonstrict-read-write, i.e. if you update many rows in a single db transaction the updated cache objects are available for other threads immediately after update, and not after all the cache objects in the transaction are updated. Or can anybody confirm that I'm wrong here (javadocs at least mention that a NonstrictReadWriteCache never locks the cache)?

If you use read-write, I think that ehcache locks the cached objects, which should make sure that cache updates for a single db transaction are also atomic.

Now, the meaning of transactional in the context of TreeCache probably means that TreeCache participates in the same transaction as the actual DB operations (it depends on JTA). This certainly ensures that updating many cache objects in a single transaction is an atomic operation. Also, I'm quite sure Treecache uses some 2-phase commit protocol to ensure that cache updates are successfully propagated to all the nodes in a cluster.

A quick rule of thumb is, transcational concurrency strategy gives you the equivalent to repeatable read isolation in a managed environment (Appserver). read-write gives you read-committed isolation basically. However always be very careful when using a cache in cases where you need transaction isolation.

Where can we get more information on caching in Hibernate?
Especially regarding what effect implementing caching will have on transaction isolation for our applications.

The manual's fairly vague in this area, do we just have to read the code of Hibernate and the cache implementation we choose (probably EHCache) and hope that we interpret it properly?

Our specific environment involves a standalone Tomcat instance, so no appserver/JTA so TreeCache can't help us.

We must have an isolation level of at least read committed.

The manual says (for "read-write" usage):

Does this mean that if we can make this guarantee about closing the session that we can assume that a competent cache implementation (ie. EHCache) will give us an isolation level of read committed?

You can get us onsite for performance tuning or direct support. See my signature.

We're not doing performace tuning yet, we're not even doing proper load testing yet (hence, we're not switching on 2nd-level caching yet).

We just want to know the transaction isolation repercussions of switching on 2nd-level caching in Hibernate so we can know whether further investigation (and possible expenditure on consultants) is warranted.

Or do we just have to look at the code and hope we understand?

For us, if read-committed isolation level can not be guaranteed (for at least some operations), then it can be dismissed as a viable possibility.

For each class or association, pick a cache concurrency strategy:

transactional: Available in a managed environment only, it guarantees full transactional isolation up to repeatable read, if required.

read-write: This strategy maintains read-committed isolation, using a timestamping mechanism and is available only in non-clustered environments.

nonstrict-read-write: Makes no guarantee of consistency between the cache and the database, uses a timeout/expiration mechanism.

read-only: A concurrency strategy suitable for data which never changes.

Then, chose a chache provider that supports your strategies and configure everything.

Did you just type all that out, or is it from some documentation we can read? :)



So, if I'm understanding correctly; if we stick to usages of "read-only" & "read-write" and use EHCache - then we're probably Okay even in a non-managed environment (ie. a basic Tomcat instance).

Or to put it a different way:
Given the above, if our DB is configured for at least read committed isolation level, then Hibernate/EHCache 2nd-level caching will also provide a read committed level of isolation for transactions.

It is from Hibernate in Action, available real soon[tm].

Your conclusion is correct.