Interesting, since you know the exact place to look, could you get the class from 3.1-CVS and verify that check has changed? I would love to investigate myself but I am pretty occupied with other stuff now.
--- Patrick Casey <[EMAIL PROTECTED]> wrote: > > Maybe they changed the behavior for default caches > in 3.1? Without a > declared cache region, the persister gets a null > cache and that's the ball > game in 3.0.5. The entire check consists of one line > of code. > > --- Pat > > > -----Original Message----- > > From: Konstantin Ignatyev > [mailto:[EMAIL PROTECTED] > > Sent: Sunday, September 25, 2005 2:40 PM > > To: Tapestry users > > Subject: RE: Hibernate session model > > > > 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> > > > > > > > > > > === message truncated === --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
