O diagrama abaixo fornece uma visão de altíssimo nível da arquitetura do Hibernate:

Nós não temos o escopo neste documento para mostrar uma visão mais detalhada da arquitetura em execução. O Hibernate é muito flexível e suporta várias abordagens. Mostraremos os dois extremos. No entanto, nós apresentaremos os dois extremos: arquitetura "mínima" e arquitetura "compreensiva".

Este diagrama mostra o Hibernate usando o banco de dados e a configuração de dados para prover persistência de serviços e persistência de objetos para o aplicativo.

Na arquitetura "mínima", o aplicativo fornece suas próprias conexões JDBC e gerencia suas transações. Esta abordagem usa o mínimo de subconjuntos das APIs do Hibernate:

A arquitetura "compreensiva" abstrai a aplicação do JDBC/JTA e APIs adjacentes e deixa o Hibernate tomar conta dos detalhes.

Algumas definições dos objetos descritos nos diagramas:

Dada uma arquitetura "mínima", o aplicativo passa pelas APIs Transaction/TransactionFactory e/ou ConnectionProvider para se comunicar diretamente com a transação JTA ou JDBC.

Uma instância de classes persistentes pode estar em um dos três diferentes estados, que são definidos respeitando um contexto persistente. O objeto Session do Hibernate é o contexto persistente. Os três diferentes estados são os seguintes:

JMX é o padrão do J2EE para manipulação de componentes Java. O Hibernate pode ser manipulado por um serviço JMX padrão. Nós fornecemos uma implementação do MBean na distribuição: org.hibernate.jmx.HibernateService.

Para um exemplo de como implementar o Hibernate como um serviço JMX em um Servidor de Aplicativo JBoss, por favor, consulte o Guia do Usuário do JBoss. No JBoss As, você poderá ver os benefícios de se fazer a implementação usando JMX:

Consulte o manual do usuário do JBoss AS, para obter maiores informações sobre essas opções.

Another feature available as a JMX service is runtime Hibernate statistics. See Seção 3.4.6, “Estatísticas do Hibernate” for more information.

O Hibernate pode também ser configurado como um conector JCA. Por favor, visite o website para maiores detalhes. Observe também, que o suporte do JCA do Hibernate ainda é considerado experimental.

A maioria das aplicações que usa o Hibernate necessita de algum tipo de sessão "contextual", onde uma sessão dada é na verdade um escopo de um contexto. Entretanto, através de aplicações, a definição sobre um contexto é geralmente diferente; e contextos diferentes definem escopos diferentes. Aplicações usando versões anteriores ao Hibernate 3.0 tendem a utilizar tanto sessões contextuais baseadas em ThreadLocal, classes utilitárias como HibernateUtil, ou utilizar frameworks de terceiros (como Spring ou Pico) que provê sessões contextuais baseadas em proxy.

A partir da versão 3.0.1, o Hibernate adicionou o método SessionFactory.getCurrentSession(). Inicialmente, este considerou o uso de transações JTA, onde a transação JTA definia tanto o escopo quanto o contexto de uma sessão atual. Dada a maturidade de diversas implementações autônomas disponíveis do JTA TransactionManager, a maioria (se não todos) dos aplicativos deveria utilizar o gerenciador de transações JTA sendo ou não instalados dentro de um recipiente J2EE. Baseado neste recurso, você deve sempre utilizar sessões contextuais baseadas em JTA.

Entretanto, a partir da versão 3.1, o processo por trás do método SessionFactory.getCurrentSession() é agora plugável. Com isso, uma nova interface (org.hibernate.context.CurrentSessionContext) e um novo parâmetro de configuração (hibernate.current_session_context_class) foram adicionados para possibilitar a compatibilidade do contexto e do escopo na definição de sessões correntes.

Consulte no Javadocs sobre a interface org.hibernate.context.CurrentSessionContext para uma discussão detalhada. Ela define um método único, currentSession(), pelo qual a implementação é responsável por rastrear a sessão contextual atual. Fora da caixa, o Hibernate surge com três implementações dessa interface:

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, Transações e Concorrência for more information and code examples.

O parâmetro de configuração hibernate.current_session_context_class define qual implementação org.hibernate.context.CurrentSessionContext deve ser usada. Note que para compatibilidade anterior, se este parâmetro de configuração não for determinado mas um org.hibernate.transaction.TransactionManagerLookup for configurado, Hibernate usará o org.hibernate.context.JTASessionContext. Tipicamente, o valor deste parâmetro nomearia apenas a classe de implementação para usar; para as três implementações fora da caixa, entretanto, há dois pequenos nomes correspondentes, "jta", "thread", e "managed".