Pregunta

Tengo una aplicación grande que utiliza beans de entidad (BMP) EJB 2.x.Es bien sabido que esta es una estrategia de persistencia horrible (puedo dar más detalles si es necesario).

Me gustaría comenzar a migrar esta aplicación para utilizar una estrategia de persistencia mucho más expresiva, transparente y no invasiva y, dada la experiencia previa de mi empresa con ella, Hibernate 3.x es la opción obvia.

Migrar a Hibernate llevará un tiempo, ya que más de 100 tablas en la aplicación utilizan beans de entidad.Así que estoy considerando un enfoque por fases en el que las dos estrategias de persistencia se ejecutan en paralelo, idealmente en las mismas tablas al mismo tiempo, si es posible.

Mi pregunta es, ¿cuáles son los riesgos (si los hay) de combinar estas dos estrategias de persistencia?¿Se interpondrán el uno en el camino del otro?

¿Fue útil?

Solución

Como dijo jodonnel, debe prestar atención al almacenamiento en caché, porque si usa el almacenamiento en caché de segundo nivel en Hibernate y se modifica una tabla fuera de Hibernate, entonces Hibernate no tiene forma de saber que su entrada de caché está obsoleta.

Para las transacciones, ambos deben usar JTA proporcionado por el contenedor, por lo que debe ser seguro.

Otros consejos

Supongo que lo que hay que tener realmente en cuenta es trabajar con las sesiones de Hibernate.Hibernar almacena en caché cosas, y eso podría interponerse en el camino.

Francamente, recomendaría que si adopta Hibernate, elimine los Entity beans por completo.Haga su trabajo de Hibernate dentro de los beans de sesión y deje que los beans de sesión administren sus transacciones.

O, alternativamente, utilice EJB 3, que está estandarizado por Hibernate en la API de persistencia de Java.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top