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>
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
