Le diagramme ci-dessus procure une vue - (très) haut niveau - de l'architecture Hibernate :

Nous aimerions décrire une vue plus détaillée de l'architecture. Hibernate est flexible et prend en charge différentes approches. Nous allons en montrer les deux extrêmes : l'architecture "légère" et l'architecture "complète".

Ce diagramme montre Hibernate utilisant la base de données et des données de configuration pour fournir un service de persistance, et des objets persistants, à l'application.

L'architecture "légère" permet à l'application de fournir ses propres connexions JDBC et de gérer ses propres transactions. Cette approche utilise un sous-ensemble minimum des API Hibernate :

L'architecture "complète" abstrait l'application des API JDBC/JTA sous-jacentes et permet à Hibernate de s'occuper des détails.

Voici quelques définitions des objets dans les diagrammes :

Dans une architecture légère, l'application n'aura pas à utiliser les API Transaction/TransactionFactory et/ou n'utilisera pas les API ConnectionProvider pour utiliser directement JTA ou JDBC.

Une instance d'une classe persistante peut être dans l'un des trois états suivants, définis par rapport à un contexte de persistance. L'objet Session Hibernate correspond à ce contexte de persistance. Les trois états distincts sont:

JMX est le standard J2EE de gestion des composants Java. Hibernate peut être géré via un service JMX standard. Nous fournissons une implémentation d'un MBean dans la distribution : org.hibernate.jmx.HibernateService.

Pour un exemple sur la manière de déployer Hibernate en tant que service JMX dans le serveur d'application JBoss Application Server, référez vous au guide de l'utilisateur JBoss (JBoss User Guide). Si vous déployez Hibernate via JMX sur JBoss AS, vous aurez également les avantages suivants :

Consultez le guide d'utilisation de JBoss AS pour plus d'informations sur ces options.

Another feature available as a JMX service is runtime Hibernate statistics. See Section 3.4.6, « Statistiques Hibernate » for more information.

Hibernate peut aussi être configuré en tant que connecteur JCA. Référez-vous au site web pour de plus amples détails. Il est important de noter que le support JCA de Hibernate est encore considéré comme expérimental.

Certaines applications utilisant Hibernate ont besoin d'une sorte de session "contextuelle", où une session donnée est en effet liée à la portée d'un contexte particulier. Cependant, les applications ne définissent pas toutes la notion de contexte de la même manière, et différents contextes définissent différentes portées à la notion de "courant". Les applications qui utilisaient Hibernate, versions précédentes à la 3.0, avaient tendance à employer un principe maison de sessions contextuelles basées sur le ThreadLocal, ainsi que sur des classes utilitaires comme HibernateUtil, ou utilisaient des framework tiers (comme Spring ou Pico) qui fournissaient des sessions contextuelles basées sur l'utilisation de proxy/interception.

A partir de la version 3.0.1, Hibernate a ajouté la méthode SessionFactory.getCurrentSession(). Initialement, cela demandait l'usage de transactions JTA, où la transaction JTA définissait la portée et le contexte de la session courante. L'équipe Hibernate pense que, étant donnée la maturité des nombreuses implémentations autonomes du JTA TransactionManager, la plupart (sinon toutes) des applications devraient utiliser la gestion des transactions par JTA qu'elles soient ou non déployées dans un conteneur J2EE. Par conséquent, il vous suffira de contextualiser vos sessions via la méthode basée sur JTA.

Cependant, depuis la version 3.1, la logique derrière SessionFactory.getCurrentSession() est désormais enfichable. A cette fin, une nouvelle interface d'extension(org.hibernate.context.CurrentSessionContext et un nouveau paramètre de configuration hibernate.current_session_context_class ont été ajoutés pour enficher la portée et le contexte de sessions courantes caractéristiques.

Pour une description détaillée de son contrat, consultez les Javadocs de l'interface org.hibernate.context.CurrentSessionContext. Elle définit une seule méthode, currentSession(), par laquelle l'implémentation est responsable de traquer la session contextuelle courante. Hibernate fournit trois implémentations de cette 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 Chapitre 12, Transactions et Accès concurrents for more information and code examples.

Le paramètre de configuration hibernate.current_session_context_class définit quelle implémentation de org.hibernate.context.CurrentSessionContext doit être utilisée. Notez que pour assurer la compatibilité avec les versions précédentes, si ce paramètre n'est pas défini mais qu'un org.hibernate.transaction.TransactionManagerLookup est configuré, Hibernate utilisera le org.hibernate.context.JTASessionContext. La valeur de ce paramètre devrait juste nommer la classe d'implémentation à utiliser. Pour les trois implémentations prêtes à utiliser, toutefois, il y a trois noms brefs correspondants : "jta", "thread" et "managed".