2010-12-22 7 views
11

Al integrar dos subsistemas, nos vimos obligados a utilizar varias instancias de SessionFactory, lo que generaba problemas al interactuar con nuestro caché de segundo nivel de Hibernate (Terracotta EhCache). Específicamente:¿Cuáles son las implicaciones de usar SingletonEhCacheRegionFactory vs. EhCacheRegionFactory para la memoria caché de segundo nivel de Hibernate en una aplicación web?

for(CacheManager cm : CacheManager.ALL_CACHE_MANAGERS){ 
      LOGGER.log(Level.DEBUG, "In cm " + cm.getName()); 
      for(String cn : cm.getCacheNames()){ 
       LOGGER.log(Level.DEBUG, "I have a cache called " + cn); 
       LOGGER.log(Level.DEBUG, "it's status is " + ms.getCache(cn).getStatus()); 
      } 
     } 
    try{ 
    myCollection.size(); 
    }catch(IllegalStateException ise){ 
     LOGGER.log(Level.FATAL, ise); //Triggered 
    }   

La depuración impresión de muestra STATUS_ALIVE de caché "Foo", pero la llamada a size() lanza una IllegalStateException:

java.lang.IllegalStateException: The Foo Cache is not alive. 

En la actualidad, ambos SessionFactories están configurados para utilizar SingletonEhCacheRegionFactory . Si cambio los SessionFactories para usar EhCacheRegionFactory (no singleton), ¿cuáles son las ramificaciones para el comportamiento del caché (específicamente en un contexto de aplicación web)?

+0

¿Está utilizando dos fábricas de sesión, pero dentro de la misma aplicación? ¿Las fábricas son similares o están configuradas por separado? – jpkrohling

+0

Sí. Estamos migrando de un modelo de datos existente a un nuevo modelo de datos brillante y tenemos que lidiar con ambos al integrarnos con los sistemas heredados. Entonces son "similares" pero no idénticos. –

+0

no estoy seguro si esto ayuda: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3450 –

Respuesta

6

EhCache se asegurará de que todas las instancias de SingletonEhCacheRegionFactory utilicen la misma CacheManager internamente, sin importar cuántas instancias de SingletonEhCacheRegionFactory cree, convirtiéndola en una versión cruda del patrón de diseño de Singleton.

La llanura EhCacheRegionFactory, por otra parte, obtendrá un nuevo CacheManager cada vez.

Si tiene dos fábricas de sesión de Hibernate en Spring, cada una con su propia instancia de SingletonEhCacheRegionFactory, entonces realmente terminarán compartiendo mucho de su estado de caché, lo que puede explicar su problema.

Esto no es realmente una buena combinación para Spring, donde se supone que los singleton son administrados por el contenedor. Si usa EhCacheRegionFactory, es probable que obtenga resultados más predecibles. Sugiero probarlo y ver cómo te va.

Cuestiones relacionadas