I. Introduction

L’objectif de cette formation est de comprendre le contexte de persistance et le flushing, que ce soit avec l’API Native ou l’API JPA d’Hibernate.

II. Prérequis

Ayant consulté la formation « [Hibernate] Vue d’ensemble ».

III. Contexte de persistance

L'API Native avec son interface org.hibernate.Session et l'API JPA avec son interface javax.persistence.EntityManager représentent un contexte pour traiter les données persistées ou à persister. Ce concept est appelé un contexte de persistance. Les données (ou entités) sont à un état spécifique (à un instant T) par rapport à la fois à un contexte de persistance et à la base de données utilisée.

Règle :

Nous ne pouvons maintenir qu'un seul objet (entité) avec le même identifiant dans un contexte de persistance. Cela ressemble au concept de la clé primaire pour les SGBD relationnels.

IV. Cycle de vie

Cycle de vie : l’ensemble des états par lesquels passe une entité obligatoirement (ou pas), par rapport à un contexte de persistance : Session ou EntityManager.

Voici donc les quatre états possibles :

1. L’état transitoire (Transient = created = new) : 

L'entité vient d'être instanciée et n'est pas associée à un contexte de persistance. Elle n'a pas de représentation persistante dans la base de données et généralement aucun identifiant ne lui a été attribué encore (sauf si la stratégie de génération assigned a été utilisée).

èL’objet n’a jamais été persisté au préalable, il n’est associé à aucune session ou entityManager.

2. L’état persisté (Managed = persistent):

L'entité a un identifiant et associée à un contexte de persistance. Elle peut exister physiquement ou pas encore dans la base de données.

èL’objet est associé à un contexte avec un identifiant unique : deux objets avec le même identifiant ne peuvent pas se trouver dans un même contexte de persistance.

3. L’état détaché (Detached) :

L'entité a un identifiant mais n'est plus associée à un contexte de persistance (généralement lorsque le contexte de persistance est vidé, fermé ou que l'instance a été expulsée du contexte)

èL’objet a été précédemment à l’état persisté mais il n’est plus associé au contexte : c’est possible de le rattacher à nouveau avec L’objet Session. L’objet EntityManager n’offre pas malheureusement cette possibilité.

4. L’état supprimé (Removed):

L'entité a un identifiant et a été associée à un contexte de persistance auparavant.  Cependant, il est prévu d’effectuer la suppression dans la base de données au moment du flushing ou du commit.

V. Cycle de vie : vérifier l’état d’un objet

Vérification de l'état avec l’API JPA :

boolean contained = entityManager.contains(obj);

Vérification de l'état avec l'API Native :

boolean contained = session.contains(obj);

Remarques :

Si contained retourne true, cela signifie que l’objet obj dispose forcément d’un identifiant et qu’il est à l’état persisté.

Si contained retourne false et:

• que L’objet a un identifiant et a été persisté auparavant, il est considéré à l’état détaché.
• si l’objet n’a pas d’identifiant et/ou n’a jamais été persisté auparavant, il est considéré à l’état transitoire.

VI. Le flushing

1. Définition

Le flushing est la validation des modifications dans la base de données à partir d’un contexte de persistance. Les deux interfaces EntityManager et Session exposent un ensemble de méthodes qui modifient l'état de persistance d'une entité.

Syntaxe :

session.flush(); 
//ou 
entityManager.flush();

Le flushing est donné par l’option org.hibernate.flushMode pour l’API Native par le biais d’un objet Session à travers quatre stratégies différentes.

Tandis que L’API JPA (objet EntityManager) ne définisse que deux stratégies de flushhing (AUTO et COMMIT) via l’option javax.persistence.flushModeType

2. Les options du flushing :

Voici donc les options de flushing :

a. ALWAYS (Session uniquement)

Flush la session avant chaque requête sur la base de données. Ce mode déclenche un flushing du contexte de persistance même lors de l'exécution d'une requête SQL native.

b. AUTO (Session et EntityManager)

Il s'agit du modepar défaut : il ne met à jour le contexte de persistance que si nécessaire.

c. COMMIT (Session et EntityManager)

Le contexte de persistance essaie de retarder le flushing jusqu'à ce que la transaction en cours soit validée, bien qu’il puisse se mettre à jour prématurément : on peut donc parler d’un forçage de validation en fin de transaction pour assurance.

d. MANUAL (Session uniquement)

Le flushing de session est délégué à l'application, qui est obligée d’appeler Session.flush() explicitement afin d'appliquer les changements de contexte de persistance.

3. Le flushing : changement et vérification

Syntaxe pour changer la stratégie de flushing avec Session :

session.setHibernateFlushMode(FlushMode.COMMIT);

Afficher la stratégie de flushing utilisée avec Session :

session.getHibernateFlushMode();

Syntaxe pour changer la stratégie de flushing avec EntityManager :

entityManager.setFlushMode(FlushModeType.AUTO);

Afficher la stratégie de flushing utilisée avec EntityManager :

entityManager.getFlushMode();

4. Le flushing : remarque

Les modifications apportées aux instances persistées sont détectées de façon automatique au moment du flushing, Il n'est pas nécessaire d'appeler explicitement une méthode particulière pour rendre vos modifications persistantes.

Exemple :

PersonneAnnot person = session.byId(PersonneAnnot.class).load(id);

person.setNom("Hachim IDRISSI YASSINE");

session.flush();

VII. Schéma récapitulatif

Conclusion

Dans l’étape suivante, nous allons découvrir comment gérer les transactions avec les deux APIs d’Hibernate.