Unfortunately I used up all my "playing with interstesting problems"
time for the day already I think. ATM I'm hip deep in trying to get Sun's
new Web Services stack working since folks I know swear it's dramatically
more efficient than Axis.
--- Pat
PS I did open a JIRA bug on the negative session timestamp issue.
I'm still not sure enough what's afoot with the cache stuff to bug it yet. I
know that it's not finding a cache, but I haven't traced the startup to
figure out why there's a null cache in the persister in the first place.
> -----Original Message-----
> From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 25, 2005 3:15 PM
> To: Tapestry users
> Subject: RE: Hibernate session model
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
