1

I have a strange behavior with caching and JPA Entities (EclipseLink 2.4.1 ) + GUICE PERSIST

I will not use caching, nevertheless I get randomly an old instance that has already changed in MySQL database.

I have tried the following:

  1. Add @ Cacheable (false) to the JPA Entity.

  2. Disable Cache properties in the persistence.xml file :

     <class>MyEntity</class>
     <shared-cache-mode>NONE</shared-cache-mode>    
     <properties>      

            <property name="eclipselink.cache.shared.default" value="false"/>
         <property name="eclipselink.cache.size.default" value="0"/>
        <property name="eclipselink.cache.type.default" value="None"/>
        <property name="eclipselink.refresh" value="true"/>
        <property name="eclipselink.query-results-cache" value="false"/>
            <property name="eclipselink.weaving" value="false"/>          
     </properties>

Even activating trace EclipseLink, i see the JPQL query:

ReadObjectQuery Execute query (name = "readObject" referenceClass = XX sql = "... (just making a call" find "the entityManager

but, However randomly returns an old value of that class.

Note

Perhaps happens for using different instances of EntityManager and everyone has their cache? I have seen the following related post : Disable JPA EclipseLink 2.4 cache If so, is possible to clear the cache of ALL EntityManager whithout using : ???? em.getEntityManagerFactory().getCache().evictAll(); Is it possible to clear ALL caches whithout using evictALL ??

Azimuts
  • 1,102
  • 3
  • 14
  • 33

1 Answers1

1

Evict all is for the shared cache which you have disabled already anyway. EntityManager instances are required by default to have a first level cache of their own to keep track of all managed instances they have created. An entityManager is meant to represent logical transactions and so should not be long lived. You need to throw away your EntityManagers and re obtain them or just clear them at logical points rather than let the number of managed entitites in its cache grow endlessly. This will also help limit the stale data issue, though nothing other than pessimistic locking can eliminate it. I recommend using optimistic locking if you aren't already to avoid overwriting with stale data.

Chris
  • 17,615
  • 1
  • 26
  • 38
  • To manage the JPA persistence I am using [GUICE PERSIST](https://code.google.com/p/google-guice/wiki/GuicePersist). Every time I do a JPA transaction, I get an instance of Entity Manager via injecting a provider of an EntityManager : '@Inject Provider' .. Maybe the instance of the EntityManager returned by the Provider is not refreshed?? – Azimuts Jan 08 '14 at 08:34
  • In the doc you linked, GUICE describes a session per transaction as well as a session per http request. The first sounds like what I described - short lived based on the current transaction, while the second seems longer lived and will cache what you've read in. If using the second, you need to call em.clear() to clear the local cache when necessary. – Chris Jan 08 '14 at 15:47
  • Thanks Chris . The documentation actually speaks of two types (Session -per -transaction strategy / session- per -http -request ) However, it is somewhat confusing. Typically , as explained in the documentation for a Web application , is to define the point of entry into a servlet ( "session -per -http- request") . However, if you see in the documentation where you set the entry point of the persistence in a Servlet , notice the following: 'public class extends MyModule ServletModule {   protected void configureServlets () {     install (new JpaPersistModule ( " myJpaUnit " ) )' – Azimuts Jan 09 '14 at 08:12
  • This is the most common way . But if you notice, what u do there is call a persistence.xml file where you have : So, What kind of strategy you are using session- per -transaction strategy ( RESOURCE_LOCAL ) or session- per -http -request ?????? It is a bit confusing. There is a "dirty" way , I've read on forums, to associate one EntityManager via AOP Interceptor ( bindInterceptor ) so that the instance you back before you make a " clear" to the instance .. It is a bit confusing. – Azimuts Jan 09 '14 at 08:15
  • Persistence unit properties are independent to the Guice settings, and only specify how/who will control the transactions and tie them to the EM (resource-local vs JTA). The Guice settings are the issue, as if you have the em tied to the Http session, everything read through that http session is cached in the EM. This allows all changes to be picked up and flushed when a transaction starts and commits, but comes at a cost - the memory used by the cache and the inability to pick up changes made elsewhere without either refreshing or clearing the cache. – Chris Jan 09 '14 at 14:45