Interesting ... concerning 2) Wouldn't it work if you wouldn't spawn your secondary sessions from the same jdbc-Connection? Or do I miss something here?
Basically Hibernate's behaviour, to me, seems necessary to make using the more restrictive transaction isolation levels, like "repeatable-read" or "serializable", possible. If Hibernate would allow a session to see Objects as read (or written) by sessions which commenced later, you would possible have non-repeatable reads and phantom reads. Thus nullifying you DB's tremendous efforts to prevent them ;). But, maybe it would be nice of Hibernate to enable one to switch its cache usage to a read-committed isolation-level ... And, hey, it's not that bad: Even long sessions don't last forever ;). In my Apps (with long sessions) I get fairly good cache-usage (think of all the really long-lasting objects, which will lurk in your cache for days or even for server-uptime. > 1) Despite what the ehCache documentation says about > using default > cache regions, it will *not* use a default cache region for > second level > cache. If you don't manually create a cache in your > ehcache.xml for a given > persistent class, the default hibernate Persister will get > back a null cache > and treat the entity as uncacheable. > > 2) Even if you do set up a cache propertly, you cannot use a > read-write cache with a secondary session. > > If you do > > Session s = SessionFactory.openSession(); > > You get a first level session with a session timestamp = its > creation date. > > If you do: > > Session temp = SessionFactory.openSession(s.connection()); > > You get back a secondary session that bootstraps off of > the primary > session's JDBC connection. This secondary session though > *does not* have a > valid session timestamp. In fact it defaults to a very large negative > number, thereby ensuring that any time this session tries to > fetch data from > the L2 cache, it appears as though the data was put in cache after the > session was created and Hiberate treats it as though it were > soft locked. > > If you, like me, are in the habit of using temporary sessions to > load bulk data (so as not to clutter up the primary session > with lots of > persistent instances that I don't need), then you basically > can't use the > secondary cache :(. > > 3) The second level cache has a built in freshness > test. An object > is considered "fresh" if it was put in the cache before the requesting > session was *created*. Thus conider: > > At 12:00 I create Session foo. > At 12:01 I do a query through foo and put some stuff in > L2 cache. It > goes in with a "freshness date" of 12:01. > > At 12:02 I create a session bar. > At 12:03 I do a query through bar that hits the L2 > cache. The data > (with freshness of 12:01, < 12:02) is fresh. > > So that works. > > What if though we're using a long session pattern. > > At 12:00 I create Sesion foo. > At 12:01 I create Session bar. > > At 12:10 I do a query via foo. Data goes into L2 cache. It has a > "freshness date" of 12:10. > > At 12:15 I do a query via bar that hits the L2 cache. > The data (with > freshness 12:10) is considered *not fresh* because it was put > in cache after > the creation date of session bar. > > In any event, it is there, it does work, but the > implementation is > such that it really only works if you treat your Sessions as highly > transient entities. With long sessions or session per thread, > you basically > can't make use of the second level cache because of points 2 > and 3 above. > > Exasperating, but that's the way it is I suppose. I'm honestly > flummoxed though as to why the Hibernte documentation and > books push the > long session (or session per thread) patters so aggressively > when using > either of those patterns pretty much guarantees you can't use > the L2 cache. > > --- Pat > > > -----Original Message----- > > From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED] > > Sent: Sunday, September 25, 2005 12:03 PM > > To: Tapestry users > > Subject: RE: Hibernate session model > > > > No, I do not use the same session. The code is a bit > > confusing because I did not include the whole source. > > The method getCurrentSession() should be named > > getOrCreateCurrentSession(). If you look closely to my > > code than you will see that I explicitly close the > > current session with closeSession() call therefore > > next call to getCurrentSession() actually creates new > > session. > > > > So all the caching happens in the L2 ehcache. > > What is different from your example: > > - I do not use criteria API and issue HQL directly, > > - I use H3.1-CVS current > <snip> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
