Hibernate.orgCommunity Documentation

Capítulo 2. Arquitectura

2.1. Sinopsis
2.2. Estados de instancia
2.3. Integración JMX
2.4. Soporte JCA
2.5. Sesiones contextuales

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:

SessionFactory (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.

Session (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 y colecciones persistentes

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).

Objetos y colecciones transitorios y separados

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.

Transaction (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 Transactiones. Sin embargo, la demarcación de la transacción, ya sea utilizando la API subyacente o Transaction, nunca es opcional.

ConnectionProvider (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.

TransactionFactory (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.

Extension Interfaces

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:

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:

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:

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".