Hibernate

Interface org.hibernate.SessionFactory

org.hibernate.SessionFactory est une interface dont le rôle principal est la création d'instance de classes implémentant l'interface org.hibernate.Session. Dans une application on a une seule instance d'une classe implémentant org.hibernate.SessionFactory et par la suite les demandes(requêtes) des clients obtiennent des instances de classes implémentant org.hibernate.Session à partir de cette SessionFactory. L'état interne de SessionFactory est immuable i.e qu'une fois qu'il est créé c'est lui qui est pris en compte tout au long de l'applicatrion. Cet état interne inclut toutes les métadonnées de la Cartographie d'Objet/Relationnel . Cet objet immuable tout long de l'application est obtenu comme suit :

 SessionFactory sessionFactory = new org.hibernate.cfg.Configuration().configure().buildSessionFactory();

La classe "org.hibernate.Configuration" permet d'atteindre les fichiers de configuration et les fichier de mapping des classes à mapper (POJO). L'objet Configuration lit les fichiers <nom-classe>.hbm.xml pour mettre en place le cadre de persistance; L'initialisation SessionFactory est chargée en mémoire et prend en compte les fichiers de configuration dans l'ordre suivant :

  1. le contenu de hibernate.properties
  2. le contenu de hibernate.cfg.xml
  3. les contenus de tous les mapping mentionnés dans hibernate.cfg.xml  

Une fois que la fabrique de session (SessionFactory) est créée, une connexion est créée et par la méthode openSession() on ouvre une session:

Session session = sessionFactory.openSession();

Après avoir ouvert et travaillé avec une session, on termine par close() de type void; cette méthode ferme la Session en relâchant toutes les ressources à savoir les caches, le jeu de connexions,etc ...

Interface org.hibernate.Session

L'interface org.hibernate.Session a un rôle centrale car il permet, de créer la connection à la base de données, de lire ou de détruire toute opération relative aux instances des classes java mappées ; c'est cet interface qui va réellement s'occuper de la notion de persistance.
Chaque instance d'objet mappé peut être dans un des états suivants:

transient : jamais persitante et non associé à une quelconque Session
peristent : associée à une et une seule Session
datached : précédemment persistante , non associée à une quelconque Session

Le cycle de vie d'une session est borné par le début et la fin d'une transaction logique (une longue transaction logique peut être réalisée par plusieurs transactions du SGBD).
C'est seulement lorsqu'une Session est ouverte, ainsi qu'une transaction que les objets des classes persistantes peuvent profiter de cette persistance. En général la mise à jour de la base de données se fait de façon optimisée lors de la validation de la transaction logique par la méthode commit()

Méthodes pour gérer une Session
Hibernate prend en compte toutes les modifications effectuées sur les objets persistants, les traduit en ordres SQL qui peuvent être, soit des insert, update ou delete, exécutables par le SGBD. Ceci est faisable après l'éxecution de la méthode Session.flush() qui sert à synhroniser l'état de la base de données avec celui de la mémoire centrale.
Un certain nombres de méthodes de l'interface Session permettent de bien gérer les données au sein d'une session ouverte:

void org.hibernate.Session.flush()

Le flush1 consiste à exécuter les ordres SQL permettant de synchroniser l'état de la base de données avec celui de la mémoire centrale

void org.hibernate.Session.clear()
Pour vider le cache (gestion des ressources).
org.hibernate.Session.close ()
fin de la session
org.hibernate.Session.commit()
Par défaut un flush est effectué aux instants suivants :
avant l'évaluation d'une requête,
lors du org.hibernate.Session.commit() de la Transaction
lors d'un appel explicite à flush() (ouf !)

Remarque
La documentation précise qu'un flush doit être exécuté avant l'évaluation d'une requête
Voici deux possibilités pour éviter la saturation du cache de second niveau :

Désactiver le cache de second niveau :
  - hibernate.cache.use_second_level_cache false 
  - hibernate.jdbc.batch_size 20 taille du paquet JDBC.

ou bien en appelant successivement, éventuellement plusieurs fois dans une même transaction logique, les deux méthodes suivantes :
session.flush() ; // Effectue toutes les modification en mémoire centrale dans la BD
et session.clear(); // Détruit toutes les instances mappées ainsi que save update delete

Interface org.hibernate.Transaction

La transaction telle qu'elle est définie ici n'a rien à voir avec les transactions sous-djacentes au SGBD sur lequel s'appuie Hibernate . C'est pourquoi on parle de transaction logique; on la définit au sein d'une session Hibernate et elle est instanciée par la méthode "Session.beginTransaction()" qui returne une instance Transaction et peut recouvrir plusieurs transaction du SGBD.
La création des transactions est liée à la propriété "hibernate.transaction.factory_class" qui indique la fabrique (factory) à utiliser. Par défaut cette fabrique est JDBCTransactionFactory qui fournit des JDBCTransaction. Ces deux classes se trouvent dans le paquetage "org.hibernate.transaction".
Si Hibernate fonctionne au dessus de JDBC, alors il nécessite que le auto commit soit à faux. La durée de vie d'une session correspond à exactement une transaction. Une idée est que pendant une transaction (et donc sa session) aucun dialogue interactif avec l'utilisateur ne doit avoir lieu. Si ce n'est pas le cas, la durée de la transaction risque d'être très longue et de dégrader les performances transactionnelles, par exemple si un verrou est posé en début de transaction sur une table pendant une heure parce que l'utilisateur a dû discuter avec ses collaborateurs pour prendre une décision.

Méthodes pour gérer une Transaction
La métode commit() de JDBCTransaction( returne un void) fait le flush de la Session associée ê la transaction et la transaction du SGBD est validée si elle a été démarrée par cette transaction logique.
De même la méthode de JDBCTransaction rollback() ( returne un void) force la transaction correspondante du SGBD à faire un rollback.