Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>JPA 1.0 standard had no caching included (and JPA 1.2 doesn't exist).</p> <p>JPA 2.0 standard introduced caching - including the Shared Cache (a "first level cache" for each EntityManagerFactory instance) and the Application cache (second level cache for ALL EntityManagerFactor instances). Also each PersistenceContext for each EntityManager instance acts as its own lowest level cache - the "zero level cache".</p> <p>What this means is that your behaviour is all specific to Hibernate 4.1.7 and has nothing to do with any standard or any other product.</p> <blockquote> <p><em>Caching is not used when the the data cache does not have any cached data for an id in a query result.</em></p> </blockquote> <p>That's a direct quote from Apache OpenJPA docs, not Hibernate or JPA spec. You can ignore, but seems it would be true for Hibernate.</p> <blockquote> <p><em>Queries that result in projections of custom field types or BigDecimal or BigInteger fields are not cached.</em></p> </blockquote> <p>That's a direct quote from Oracle Kodo JPA docs, not Hibernate or JPA spec. Might be wise to ignore this.</p> <blockquote> <p><em>The query cache does not cache the state of the actual entities in the cache. It caches identifier values and results of value type. Therefore, always use the query cache in conjunction with the second-level cache for those entities which should be cached as part of a query result cache. .</em></p> </blockquote> <p>That's a direct quote from Hibernate 4.1 docs. So you can follow this advice - as long as you take it in context: it's saying to include the second-level cache if you want to cache entities returned from queries. If you don't want to cache entire entity objects, but just want to cache the results of NamedQueries containing primitive data types (projections), then the first level cache is all you need.</p> <p>My suggestion:</p> <ol> <li><p>I think the problem might be that COUNT(r) returns a BigInteger to java, which cannot be cast to Object for caching. You can call addScalar("count", Hibernate.LONG) on the query to tell hibernate to use a different type - LONG. See <a href="http://blog.pfa-labs.com/2009/12/caching-raw-sql-count-with-hibernate.html" rel="nofollow noreferrer">blog.pfa-labs.com/2009/12/caching-raw-sql-count-with-hibernate.html</a> plus <a href="https://stackoverflow.com/questions/8712066/is-can-hibernates-second-level-cache-be-used-for-count-operations">Is/Can Hibernate&#39;s Second-Level Cache be Used for COUNT() operations?</a></p></li> <li><p>The query cache should be able to handle this. The second level cache should only be needed for entity objects.</p></li> <li><p>Be very careful you understand the read/write behaviour of the objects you are trying to cache - and ensure the number of reads is much greater than the number of writes. Otherwise caching could give no benefit or even slow things down and cause data inconsistencies.</p></li> <li><p>Be aware that some JDBC drivers also cache data - if yours is it will affect JPA results and JPA won't even know about it. </p></li> </ol> <p>From Mike Keith's "Pro JPA 2": Most [JDBC] drivers cache connections and statements. Some caches also keep track of table or column state that is essentially transparent to the JPA provider, but that nonetheless can offer some savings in terms of not having to go to the database to get data on every call. This is generally feasible in the driver only if it is known that either the data is read-only or the driver controls database access exclusively.</p> <p>JDBC caching, if available, should be controllable via configuration settings specific to the driver.</p> <p>EDIT:</p> <p>In the first query, "order by r.validityStart" does nothing - you could remove it, and all will work.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload