Hibernate.orgCommunity Documentation
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 :
org.hibernate.SessionFactory
)Un cache threadsafe (immuable) de mappages compilés pour une base de données. En tant que fabrique de Session
et que client du ConnectionProvider
, SessionFactory
peut contenir un cache optionnel de données (de second niveau), réutilisable entre les différentes transactions, que cela soit au sein du même processus ou au niveau d'un cluster.
org.hibernate.Session
)Un objet mono-threadé, à durée de vie courte, qui représente une conversation entre l'application et l'entrepôt de persistance. Encapsule une connexion JDBC. Fabrique des objets Transaction
. La Session
contient un cache (de premier niveau) des objets persistants, qui sont utilisés lors de la navigation dans le graphe d'objets ou lors de la récupération d'objets par leur identifiant.
Objets mono-threadés à vie courte, contenant état persistant et fonction commerciale. Ceux-ci sont en général des objets ordinaires de type JavaBean (ou POJO); la seule particularité est qu'ils sont associés avec une (et une seule) Session
. Dès que la Session
est fermée, ils sont détachés et libres d'être utilisés par n'importe quelle couche de l'application (par ex. de et vers la présentation).
Instances de classes persistantes qui ne sont actuellement pas associées à une Session
. Elles ont pu être instanciées par l'application et ne pas avoir (encore) été persistées, ou elle ont pu être instanciées par une Session
fermée.
org.hibernate.Transaction
)(Optionnel) Un objet mono-threadé à vie courte utilisé par l'application pour définir une unité de travail atomique. Abstrait l'application des transactions sous-jacentes, qu'elles soient JDBC, JTA ou CORBA. Une Session
peut fournir plusieurs Transaction
s dans certains cas. Toutefois, la délimitation des transactions, via l'API d'Hibernate ou par la Transaction
sous-jacente, n'est jamais optionnelle.
org.hibernate.connection.ConnectionProvider
)(Optionnel) Une fabrique de (pool de) connexions JDBC. Abstrait l'application de la Datasource
ou du DriverManager
sous-jacent. Non exposé à l'application, mais peut être étendu/implémenté par le développeur.
org.hibernate.TransactionFactory
)(Optionnel) Une fabrique d'instances de Transaction
. Non exposée à l'application, mais peut être étendue/implémentée par le développeur.
Hibernate fournit de nombreuses interfaces d'extensions optionnelles que vous pouvez implémenter pour personnaliser le comportement de votre couche de persistance. Reportez vous à la documentation de l'API pour plus de détails.
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:
L'instance n'est pas et n'a jamais été associée à un contexte de persistance. Elle ne possède pas d'identité persistante (valeur de clé primaire).
L'instance est associée à un contexte de persistance. Elle possède une identité persistante (valeur de clé primaire) et, peut-être un enregistrement correspondant dans la base de données. Pour un contexte de persistance particulier, Hibernate garantit que l'identité persistante soit équivalente à l'identité Java (emplacement mémoire de l'objet).
L'instance a été associée au contexte de persistance mais ce contexte a été fermé, ou l'instance a été sérialisée vers un autre processus. Elle possède une identité persistante et peut-être un enregistrement correspondant dans la base de données. Pour des instances détachées, Hibernate ne donne aucune garantie sur la relation entre l'identité persistante et l'identité Java.
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 :
Gestion de la session : le cycle de vie de la Session
Hibernate peut être automatiquement liée à la portée d'une transaction JTA. Cela signifie que vous n'avez plus besoin d'ouvrir et de fermer la Session
manuellement, cela devient le travail de l'intercepteur EJB de JBoss. Vous n'avez pas non plus à vous occuper des démarcations des transactions dans votre code (sauf si vous voulez écrire une couche de persistance qui soit portable, dans ce cas vous pouvez utiliser l'API optionnelle Transaction
de Hibernate). Vous appelez le HibernateContext
pour accéder à la Session
.
Déploiement HAR :: habituellement vous déployez le service JMX Hibernate en utilisant le descripteur de déploiement de JBoss dans un fichier EAR et/ou un SAR, car il supporte toutes les options de configuration usuelles d'une SessionFactory
Hibernate. Cependant, vous devez toujours nommer tous vos fichiers de mappage dans le descripteur de déploiement. Si vous décidez d'utiliser le déploiement optionnel sous forme de HAR, JBoss détectera automatiquement tous vos fichiers de mapping dans votre fichier HAR.
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 :
org.hibernate.context.JTASessionContext
- les sessions courantes sont associées à une transaction JTA
. La logique est la même que l'ancienne approche basée sur JTA. Consultez les javadocs pour pour plus d'informations.
org.hibernate.context.ThreadLocalSessionContext
- les sessions courantes sont traquées par l'exécution du thread. Consultez les javadocs pour plus d'informations.
org.hibernate.context.ManagedSessionContext
- les sessions courantes sont traquées par l'exécution du thread. Toutefois, vous êtes responsable de lier et de délier une instance de Session
avec des méthodes statiques de cette classe. Elle n'ouvre jamais, ni ne nettoie ou ne ferme une 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 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".
Copyright © 2004 Red Hat, Inc.