Interesting analysis. However it is not quite correlate with what I see. It looks like H3 EHCache provider takes care of creation of necessary regions for cacheable objects. I think so because I do NOT conigured that cache region in ehcache.xml (well, I used to have one, but commented it out before running my test, and yes, the commented version is used in the test, I double checked it)
--- Patrick Casey <[EMAIL PROTECTED]> wrote: > > Well, you piqued my curiosity and here's what I've > found after some > quality time with the hibernate source code. The > short version is that > you're right; there is a secondary cache, and it > does cache objects. It > does, however, have certain "hidden" restrictions > that explain why it worked > in your example, but not in mine. > > 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]
