Hibernate.orgCommunity Documentation
El diagrama a continuación brinda una perspectiva a alto nivel de la arquitectura de Hibernate:
Este documento no incluye una sinopsis detallada de la arquitecturas en tiempo de ejecución disponibles; Hibernate es flexible y soporta diferentes enfoques. Sin embargo, mostraremos los dos extremos: la arquitectura "mínima" y la arquitectura "completa".
Este diagrama ilustra la manera en que Hibernate utiliza la base de datos y los datos de configuración para proporcionar servicios de persistencia y objetos persistentes a la aplicación.
La arquitectura "mínima" hace que la aplicación proporcione sus propias conexiones JDBC y que administre sus propias transacciones. Este enfoque utiliza un subgrupo mínimo de las APIs de Hibernate:
La arquitectura "completa" abstrae la aplicación de las APIs de JDBC/JTA y permite que Hibernate se encargue de los detalles.
He aquí algunas definiciones de los objetos en los diagramas:
org.hibernate.SessionFactory
)Un caché threadsafe (inmutable) de mapeos compilados para una sola base de datos. Una fábrica de Session
y un cliente de ConnectionProvider
, SessionFactory
puede mantener un caché opcional (de segundo nivel) de datos reusables entre transacciones a nivel de proceso o de clúster.
org.hibernate.Session
)Un objeto mono-hebra, de corta vida que representa una conversación entre la aplicación y el almacenamiento persistente. Envuelve una conexión JDBC y es una fábrica de Transaction
. Session
mantiene un caché requerido de primer nivel de objetos persistentes, que se utiliza cuando se navega el gráfico de objetos o mientras se buscan objetos por identificador.
Objetos de corta vida, mono-hebra contienen un estado persistente así como una funcionalidad empresarial. Estos pueden ser JavaBeans/POJOs normales. Estos se encuentran asociados con exactamente una Session
. Tan pronto como la Session
se cierre, serán separados y estarán libres para utilizarlos en cualquier capa de aplicación, (por ejemplo, directamente como objetos de transferencia de datos hacia y desde la presentación).
Instancias de clases persistentes que no se encuentran actualmente asociadas con una Session
. Pueden haber sido instanciadas por la aplicación y aún no haber sido persistidas, o pueden haber sido instanciadas por una Session
cerrada.
org.hibernate.Transaction
)(Opcional) Un objeto de corta vida, mono-hebra que la aplicación utiliza para especificar unidades atómicas de trabajo. Abstrae la aplicación de las transacciones subyacentes JDBC, JTA o CORBA. En algunos casos, una Session
puede extenderse sobre varias Transaction
es. Sin embargo, la demarcación de la transacción, ya sea utilizando la API subyacente o Transaction
, nunca es opcional.
org.hibernate.connection.ConnectionProvider
)(Opcional) Una fábrica y pool de conexiones JDBC. Abstrae a la aplicación del Datasource
o DriverManager
subyacente. No se expone a la aplicación, pero puede ser extendido/implementado por el desarrollador.
org.hibernate.TransactionFactory
)(Opcional) Una fábrica de instancias de Transaction
. No se expone a la aplicación pero puede ser extendido/implementado por el desarrollador.
Hibernate ofrece un rango de interfaces de extensión opcionales que puede implementar para personalizar el comportamiento de su capa de persistencia. Para obtener más detalles, vea la documentación de la API.
Dada una arquitectura "sencilla", la aplicación evita las APIs de Transaction
/TransactionFactory
y/o ConnectionProvider
, para comunicarse directamente con JTA o JDBC.
Una instancia de una clase persistente puede estar en uno de tres estados diferentes. Estos estados se definen con respecto a su contexto de persistencia. El objeto Session
de Hibernate es el contexto de persistencia. Los tres estados diferentes son los siguientes:
La instancia no está asociada con un contexto de persistencia. No tiene identidad persistente o valor de clave principal.
La instancia se encuentra actualmente asociada con un contexto de persistencia. Tiene una identidad persistente (valor de clave principal) y puede tener una fila correspondiente en la base de datos. Para un contexto de persistencia en particular, Hibernate garantiza que la identidad persistente es equivalente a la identidad Java en relación con la ubicación del objeto.
La instancia estuvo alguna vez asociada con un contexto de persistencia, pero ese contexto se cerró, o la instancia fue serializada a otro proceso. Tiene una identidad persistente y puede tener una fila correspondiente en la base de datos. Para las instancias separadas, Hibernate no establece ninguna garantía sobre la relación entre identidad persistente e identidad Java.
JMX es el estándar J2EE para la gestión de componentes Java. Hibernate se puede administrar por medio de un servicio estándar JMX. Brindamos una implementación de MBean en la distribución: org.hibernate.jmx.HibernateService
.
Para ver un ejemplo de cómo desplegar Hibernate como un servicio JMX en un servidor de aplicaciones JBoss, por favor, refiérase al manual del usuario de JBoss. JBoss AS también proporciona estos beneficios si despliega utilizando JMX:
Administración de Sesión: El ciclo de vida de la Session
de Hibernate puede estar ligado automáticamente al ámbito de una transacción JTA. Esto significa que ya no tiene que abrir ni cerrar la Session
manualmente, esto pasa a ser el trabajo de un interceptor EJB de JBoss. Además tampoco tiene que preocuparse más de la demarcación de la transacción en su código (a menos de que quiera escribir una capa de persitencia portátil, utilice la API de Transaction
de Hibernate para hacer esto). Para acceder a una Session
llame al HibernateContext
.
Despliegue HAR:: el servicio JMX de Hibernate se implementa usando un descriptor de despliegue de servicio de JBoss en un archivo EAR y/o SAR, que soporta todas las opciones de configuración usuales de una SessionFactory
de Hibernate. Sin embargo, todavía tiene que nombrar todos sus archivos de mapeo en el descriptor de despliegue. Si utiliza el depliegue HAR opcional, JBoss detectará automáticamente todos los archivos de mapeo en su archivo HAR.
Para más información sobre estas opciones, consulte el Manual de Usuario de JBoss AS.
Another feature available as a JMX service is runtime Hibernate statistics. See Sección 3.4.6, “Estadísticas de Hibernate” for more information.
Hibernate también puede ser configurado como un conector JCA. Por favor refiérase al sitio web para encontrar más detalles. Sin embargo, tenga en cuenta que el soporte de JCA de Hibernate aún está bajo desarrollo.
La mayoría de las aplicaciones que utilizan Hibernate necesitan alguna forma de sesiones "contextuales", en donde una sesión dada se encuentra en efecto en todo el campo de acción de un contexto dado. Sin embargo, a través de las aplicaciones la definición de lo que constituye un contexto es usualmente diferente y diferentes contextos definen diferentes campos de acción para la noción de actual. Las aplicaciones que utiliza Hibernate antes de la version 3.0 tienden a utilizar ya sea sesiones contextuales con base ThreadLocal
desarrollados en casa, las clases ayudantes tales como HibernateUtil
, o enfoques de terceros utilizados, como Spring o Pico, los cuales brindaban sesiones contextuales con base proxy/intercepción.
Comenzando con la version 3.0.1, Hibernate agregó el método SessionFactory.getCurrentSession()
. Inicialmente, este asumió la utilización de las transacciones JTA
, en donde la transacción JTA
definia tanto el contexto como el campo de acción de una sesión actual. Dada la madurez de númerosas implementaciones JTA TransactionManager
autónomas existentes, la mayoría, si no es que todas, las aplicaciones deberían utilizar la administración de transacciones JTA
en el caso de que se deplieguen o no en un contenedor J2EE
. Con base en esto, las sesiones contextuales basadas en JTA
es todo lo que usted necesita utilizar.
Sin embargo, desde la versión 3.1, el procesamiento detrás de SessionFactory.getCurrentSession()
ahora es conectable. Para ese fin, se ha añadido una nueva interfaz de extensión, org.hibernate.context.CurrentSessionContext
, y un nuevo parámetro de configuración, hibernate.current_session_context_class
para permitir la conexión del campo de acción y el contexto de definición de las sesiones actuales.
Refiérase a los Javadocs para la interfaz org.hibernate.context.CurrentSessionContext
para poder ver una discusión detallada de su contrato. Define un método único, currentSession()
, por medio del cual la implementación es responsable de rastrear la sesión contextual actual. Tal como viene empacada, Hibernate incluye tres implementaciones de esta interfaz:
org.hibernate.context.JTASessionContext
: una transacción JTA
rastrea y asume las sesiones actuales. Aquí el procesamiento es exactamente el mismo que en el enfoque más antiguo de JTA-sólamente. Refiérase a los Javadocs para obtener más información.
org.hibernate.context.ThreadLocalSessionContext
: las sesiones actuales son rastreadas por un hilo de ejecución. Consulte los Javadocs para obtener más detalles.
org.hibernate.context.ManagedSessionContext
: las sesiones actuales son rastreadas por un hilo de ejecución. Sin embargo, usted es responsable de vincular y desvincular una instancia Session
con métodos estáticos en esta clase: no abre, vacia o cierra una Session
.
The first two implementations provide a "one session - one database transaction" programming model. This is also known and used as session-per-request. The beginning and end of a Hibernate session is defined by the duration of a database transaction. If you use programmatic transaction demarcation in plain JSE without JTA, you are advised to use the Hibernate Transaction
API to hide the underlying transaction system from your code. If you use JTA, you can utilize the JTA interfaces to demarcate transactions. If you execute in an EJB container that supports CMT, transaction boundaries are defined declaratively and you do not need any transaction or session demarcation operations in your code. Refer to Capítulo 12, Transacciones y concurrencia for more information and code examples.
El parámetro de configuración hibernate.current_session_context_class
define cuales implementaciones org.hibernate.context.CurrentSessionContext
deben utilizarse. Para compatibilidad con versiones anteriores, si este parámetro de configuración no está establecido pero si tiene configurado un org.hibernate.transaction.TransactionManagerLookup
, Hibernate utilizará el org.hibernate.context.JTASessionContext
. Usualmente el valor de este parámetro sólamente nombraría la clase de implementación a utilizar. Sin embargo, para las tres implementaciones incluídas existen tress nombres cortos: "jta", "thread" y "managed".
Copyright © 2004 Red Hat, Inc.