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]
