-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: Hibernate caching strategy
PostPosted: Wed Mar 24, 2004 5:31 am 
Newbie

Joined: Fri Mar 12, 2004 10:02 am
Posts: 16
Hibernate has two caches, a session cache and a second level cache. The session cache is used for one session only and doesn't cache objects between sessions. I'm not talking about this cache, I'm talking about the secend level cache which is by default ehcache.

Using the nonestrict-read-write strategie, my research shows that the cache works as long as you do read only access, e.g.:
    Session-1 load( X ) -> select X .... (DB access)
    Session-2 load( X ) -> ehcache hit (no DB access)
    Session-3 load( X ) -> ehcache hit (no DB access)
If your business logic requires modifications to the object it is thrown out of the cache, e.g.:
    Session-1 load( X ) -> select X .... (DB access)
    Session-1 save( X ) -> update X .... (DB access and removal from cache)
    Session-2 load( X ) -> select X .... (DB access)
    Session-2 save( X ) -> update X .... (DB access and removal from cache)
    Session-3 load( X ) -> select X .... (DB access)
    Session-3 save( X ) -> update X .... (DB access and removal from cache)
I wonder why this is done since it wasts a lot of resources. If I update the object I have the current state of the object, why should I throw it out of the cache?

Using the read-write strategie the cache works as expected:
    Session-1 load( X ) -> select X .... (DB access)
    Session-1 save( X ) -> update X .... (DB access)
    Session-2 load( X ) -> ehcache hit (no DB access)
    Session-2 save( X ) -> update X .... (DB access)
    Session-3 load( X ) -> ehcache hit (no DB access)
    Session-3 save( X ) -> update X .... (DB access)

The documentation leaves it open what the different cache strategies do or not. Why should I chose nonestrict-read-write, where is the advantage over read-write? How do they compare to the JDBC transaction isolation levels? The transactional strategie "provides support for fully transactional cache providers" and what does that mean? Do the other cache strategies violate the ACID rule? Do certain strategies lock resources? What happens in case of a deadlock?
Can sombody shed some light on it? Post his experience with the different strategies?


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.