En mi aventura actual de aprender a hibernar y configurarlo para usar el grupo de conexiones de un servidor de aplicaciones, la mayoría de los ejemplos y recursos que existen le señalan la unión de SessionFactory a un recurso JNDI en su servidor de aplicaciones en el proceso.¿Por qué obligar a hibernar SessionFactory a un recurso JNDI?
Me pregunto cuál es el beneficio de esto? Como puede acceder al grupo de conexiones sin hacer esto.
La misma razón por la que usaría JNDI para cualquier cosa, diría: mover la configuración de la aplicación al entorno de despliegue.
Con JNDI, básicamente dice "esta aplicación necesita un SessionFactory; su nombre será X" y está contento siempre que el servidor de aplicaciones tenga un SessionFactory llamado X configurado. Este tipo de externalización tiene varios beneficios atractivos:
Se puede utilizar completamente diferentes configuraciones en diferentes máquinas (de producción y control de calidad utilizar Oracle, los desarrolladores usar HSQL, ...).
No necesita hacer que su proceso de creación tenga en cuenta las configuraciones (no más ant war_for_qa o atornillar con los perfiles de Maven).
No tiene la tentación de comprobar las configuraciones en el control de versiones, por lo que su contraseña de base de datos en vivo no será conocida por todos los temporeros, pasantes, consultores o ex empleados que alguna vez tuvieron (¡o tendrán!) Acceso a el repositorio.
Sus instrucciones de instalación/configuración no incluirán elementos como "configurar el inicio de sesión de la base de datos, edite el archivo foo.properties en el archivo WAR" lo que inevitablemente provocará que las configuraciones se sobrescriban en el servidor de producción de la peor manera posible momento porque un administrador de sistemas que ha estado trabajando todo el fin de semana implementó una GUERRA no editada porque el café se acabó el domingo por la tarde.
JNDI sólo pasa a ser la forma "estándar" de hacer esto externalización en Java, lo que significa que los nuevos desarrolladores/administradores no necesitarán dos días de entrenamiento para aprender las peculiaridades de su propio, hogar-brewn sistema de configuración que realmente es bastante ingenioso pero tiene este error extraño que nadie quiere ahondar porque es realmente raro y cualquiera que tenga una solución bastante simple, & c.
relacionadas:What is the purpose of JNDI?
@gustafc Eso fue lo que pensé. Simplemente no estaba seguro de si me estaba perdiendo algo más. Estamos utilizando JNDI para nuestro grupo de conexiones, así que supongo que me preguntaba si había un beneficio adicional para mover SessionFactory al servidor de aplicaciones también. En nuestro caso, no creo que lo haya, ya que la configuración es exactamente la misma en todos nuestros servidores. Por cierto, tu respuesta es probablemente la mejor respuesta que he visto en un tiempo en cuanto a ser muy clara e informativa. –
¿Tengo razón en que el objetivo principal es hacerlo disponible en múltiples aplicaciones implementadas en el mismo servidor? Si este es el caso, una gran ventaja es el caché compartido de segundo nivel del SF. Nuestro SF reside dentro de un '@ Singleton'' @ Startup' '@ EJB' ya que solo tenemos una aplicación implementada. – djmj
@djmj, suena factible, pero sinceramente no sé cómo los servidores de aplicaciones manejan esto, ya que nunca me he encontrado con una aplicación usando una configuración de Hibernate/JPA definida externamente, la mayoría de las aplicaciones parecen implementarse de la manera que usted describe. Puedo imaginar que tiene implicaciones en la estabilidad, la seguridad, etc. y por lo tanto * no * usa un caché de segundo nivel compartido. – gustafc