You're using the same session though aren't you in that example? So
you're really using the first level cache, not the second level cache. Or
are you creating a fresh session with currentSession?

        Try replacing your s = currentSession() calls with:

        Session s = fSessionFactory.openSession();

        And see if it still works for you. I'm suspicious that you're just
closing and then reopening the same session in the sample code you have
below (maybe I'm wrong though).

        --- Pat


> -----Original Message-----
> From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 24, 2005 11:30 PM
> To: Tapestry users
> Subject: RE: Hibernate session model
> 
> And that is not what I see, cacheable statement gets
> executed only once and for second query there are no
> trips to database, none.
> My code
> 
> public void test(Session s) throws Exception {
>         s = currentSession();
>         queryCacheableObject(s);
>         closeSession();
> 
>         s = currentSession();
>         queryCacheableObject(s);
>     }
> 
>     private void queryCacheableObject(Session s) {
>         Query query = s.createQuery("from TestObj t
> where t.name like 'a%'");
>         query.setCacheable( true );
>         List objects = query.list();
>         print( objects);
>     }
> 
> 
>     public static void main(String[] args) {
>         Test945854 t = new Test945854();
>         t.executeTests();
> 
>     }
> 
> mapping:
> <class
>       name="TestObj"
>       table="test_obj"
>       dynamic-update="true"
>       >
>       <cache usage="read-write" />
> 
>       <id
>       name="id"
>       type="java.lang.Integer"
>       unsaved-value="null"
>       >
>       <generator class="assigned">
>       </generator>
>       </id>
> 
>       <property
>       name="name"
>       type="java.lang.String"
>       />
>   </class>
> 
> configuration
> 
>  <property
> name="hibernate.cache.enable_cache">true</property>
> <property
> name="hibernate.cache.use_query_cache">true</property>
> <property
> name="hibernate.statement_cache.size">25</property>
> <property name="hibernate.cache.provider_class">
> org.hibernate.cache.EhCacheProvider</property>
> 
> --- Patrick Casey <[EMAIL PROTECTED]> wrote:
> 
> >
> >     You know, that's just not what I'm seeing. I even
> > wrote a little
> > test app.
> >
> >     Criteria c  =
> > HibHelper.getSession().createCriteria("core.User");
> >     c.setCacheable(true);
> >     List l = c.list();
> >     // the above executes a single query to fill the
> > cache
> >     // I get one and only one query in my SQL trace
> >     c =
> >
> HibHelper.getTransientTempSession().createCriteria("core.User");
> >     // a new criteria on a new session
> >     c.setCacheable(true);
> >     l = c.list();
> >     // the above should hit the cache
> >     // lo and behold, we get 1,000 individual selects
> >     // as every single key from the original select is
> > iteratively
> >     // fetshed one at a time
> >
> >     Perhaps I have something configured wrong?
> >
> >     The point in my mapping where I enable the cache:
> >
> >     <class name="core.Person" table="person"
> > dynamic-update="true">
> >             <cache usage="read-write" />
> >             /// blah blah blah
> >     </class>
> >
> >     The point in my hibernate configuration where I
> > enable ehcache:
> >
> >     <property
> >
> name="hibernate.cache.use_query_cache">true</property>
> >
> >     My ehcache.xml where I set a nice spiffy default
> > cache:
> >
> > <defaultCache
> >         maxElementsInMemory="10000"
> >         eternal="false"
> >         timeToIdleSeconds="1200"
> >         timeToLiveSeconds="1200"
> >         overflowToDisk="false"
> >         diskPersistent="false"
> >         diskExpiryThreadIntervalSeconds="120"
> >         />
> >
> >     Is there some additional parm I have to set to
> > enable the L2 object
> > cache here? Because from what I'm seeing here, the
> > keys are getting cached,
> > but the object themselves are not, leading to the
> > aforementioned 1000
> > selects by key (which is about 200X worse than just
> > one massive select).
> >
> >     --- Pat
> >
> > > -----Original Message-----
> > > From: Konstantin Ignatyev
> > [mailto:[EMAIL PROTECTED]
> > > Sent: Saturday, September 24, 2005 8:06 PM
> > > To: Tapestry users
> > > Subject: RE: Hibernate session model
> > >
> > > Query cache is slightly different thing than
> > > Hibernate's 2L cache.
> > > L2 cache holds objects and L2 cache will supply
> > > objects by keys in Query cache.
> > >
> > > --- Patrick Casey <[EMAIL PROTECTED]> wrote:
> > >
> > > >
> > > >         Henri,
> > > >
> > > >         Where are you getting your information from?
> > > > According to my copy of
> > > > Hibernate in action (pp 291 Secion 7.6.3).
> > > >
> > > >         "Note that the query cache does *not* cache the
> > > > entities returning
> > > > in the query reslut set, just the identifier
> > > > values."
> > > >
> > > >         Am I missing something here?
> > > >
> > > >         --- Pat
> > > >
> > > > > -----Original Message-----
> > > > > From: Henri Dupre
> > [mailto:[EMAIL PROTECTED]
> > > > > Sent: Saturday, September 24, 2005 9:12 AM
> > > > > To: Patrick Casey
> > > > > Cc: Tapestry users
> > > > > Subject: Re: Hibernate session model
> > > > >
> > > > > On 9/23/05, Patrick Casey
> > <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > I rather have a DB Query than a lazy
> > > > exception. And not for every
> > > > > call!
> > > > > > > The hibernate cache is here for that.
> > > > > >
> > > > > > If memory serves, the hibernate cache caches
> > > > keys, not objects.
> > > > >
> > > > > This is not true. The hibernate second level
> > cache
> > > > is a map with <key,
> > > > > object>,
> > > > > If your key is found in the cache then it
> > > > retrieves the object (memory
> > > > > or file depending on your cache
> > configuration).
> > > > > We achieve a high performance by having it
> > > > properly configured on a
> > > > > per-class basis even with complex queries.
> > > > >
> > > > > Henri.
> > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > 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]
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
> 
> 
> Konstantin Ignatyev
> 
> 
> 
> 
> PS: If this is a typical day on planet earth, humans will add fifteen
> million tons of carbon to the atmosphere, destroy 115 square miles of
> tropical rainforest, create seventy-two miles of desert, eliminate between
> forty to one hundred species, erode seventy-one million tons of topsoil,
> add 2,700 tons of CFCs to the stratosphere, and increase their population
> by 263,000
> 
> Bowers, C.A.  The Culture of Denial:  Why the Environmental Movement Needs
> a Strategy for Reforming Universities and Public Schools.  New York:
> State University of New York Press, 1997: (4) (5) (p.206)
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to