¿Qué hace un servidor de Terracotta cuando se utiliza como back-end para EHCache con Hibernate?

Mi DAL está implementado con Hibernate y quiero usar EHCache como su segundo nivel de caché con sus capacidades distribuidas (para escalabilidad y HA).
Viendo como EHCache proporciona el caché distribuido solo con Terracotta mi pregunta es ¿cuál es el rol de la instancia del servidor Terracotta? ¿También contiene datos? ¿Coordina solo la distribución entre las partes de caché particionadas?
Mi confusión deriva principalmente de this explicación con respecto a TSA que dice que el servidor contiene los datos, pero creo que tal vez en mi caso el caché y el servidor Terracotta se combinan. ¿Estoy en lo correcto?
Si el servidor contiene datos, ¿por qué no debería pasar el cuello de botella del servidor de base de datos al servidor Terracotta?¿Qué hace un servidor de Terracotta cuando se utiliza como back-end para EHCache con Hibernate?

Actualización: respuesta de Affe respondido a la segunda parte de mi pregunta, que era la parte más importante, pero sólo en caso de que alguien viene buscando la primera parte voy a decir que el servidor TC tiene que contener todos los datos que el EHCache en la memoria se mantiene y, por lo tanto, si desea un caché distribuido (no replicado), el L2 (servidor TC) también debe contener todos los objetos.

Gracias de antemano,
Itai

Fuente

2011-01-31 Ittai

La idea es que sigue siendo significativamente más rápido para ponerse en contacto con el racimo de terracota través del controlador de terracota y hacer lo que es básicamente una búsqueda Mapa, que para adquirir una conexión de base de datos y ejecutar una sentencia SQL . Incluso si eso se convierte en el punto de estrangulación de la aplicación, se esperaría que el rendimiento general aún sea significativamente más alto que un punto de estrangulación JDBC Connection + SQL. Las conexiones abiertas y los cursores abiertos son grandes fuentes de recursos en la base de datos, ¡un socket abierto al clúster de terracota no lo es!

Fuente

2011-01-31 19:19:08 Affe

Entiendo la pregunta como: por qué EHCache necesita terracota, mientras que por ejemplo, la memoria caché de JBoss está descentralizada y no necesita ningún servidor adicional – Bozho

Esa no era la pregunta en realidad, pero es un buen apéndice. – Ittai

Supongo que no tenemos claro cuál de ustedes? las declaraciones son retóricas y cuál es la pregunta real? 'Sí', lo entiende, la solución de terracota usa un clúster de servidor externo. Traté de enfocarme en la última pregunta real de por qué te molestarías en hacer tal cosa. – Affe

Puede obtener ehcache agrupado sin utilizar terracota. Tienen documentación para hacerlo a través de RMI, JGroups y JMS. Estamos usando JMS ya que tenemos una infraestructura JMS significativa para manejar la comunicación. No sé qué tan bien escalará en el largo plazo, pero nuestra preocupación actual es solo HA.

Fuente

2011-02-01 02:44:30

Gracias Matt.Indeed sin Terracotta puede obtener replicación y no distribución que no parece ajustarse a mis necesidades en cuanto a escalabilidad. – Ittai

eh puede servir como un caché de objetos muy bien con esos tipos de métodos de replicación, sin embargo, no es compatible con el anterior Hibernate SPI para el bloqueo cuando se utiliza de esa manera. Específicamente como un caché Hibernate L2 debes tener mucho cuidado, ya que Hibernate emitirá comandos de bloqueo que eh simplemente está ignorando. (el comportamiento depende de versiones específicas de ambos) – Affe

¿Qué hace un servidor de Terracotta cuando se utiliza como back-end para EHCache con Hibernate?

Respuesta

Cuestiones relacionadas