I'm trying to use some 2nd level caching in Hibernate, TreeCache in particular, but the problem seems to concern any cache provider.
Here is simplified algorithm of what is going on:
Transaction.begin (JTA or Hib)
//some business logic that updates the loaded entity
In first iteration, load searches the cache and it misses for the first time. Db fetch. Saved into cache. Sool. And here comes the update. The entity has changed meanwhile (i.e. some counter increased). Unfortunatelly update doesn;t update in cache, but instead issues db updates:(
Any subsequent iteration gets entity from cache, but its stale (still the one that was stored in first iteration after cache miss-hit)
What's the magic about that updating in cache?
Some conf details:
- (for TreeCache) in entity mapping
-jotm as jta transaction manager
-treecache.xml with some slight changes, but default one behaves same way
I dont really think it;s a conf problem, I guess it;s rather my misunderstanding of 2nd level caching or wrong approach, I dont know. Logically, I really think it should do the update in cache instead of db, especially in case of fully transactional cache like TreeCache. The db update should follow the eviction policy of the cache.
Well I will appreciate any explaination and help
One more thing
in case of Ehcache or OScache, 'load' fetches entity from db with each interation since it finds it dirty. It is dirty in cache, b/c cache was not updated on 'update' (or to be more exact on prev tx commit)...
so same problem