Gestion de session avancée avec Hibernate

Le scénario utilisé ici sera l'insertion de 10 000 enregistrements en une seule transaction. Pour cela, nous utilisons un module de réservation de transport qui utilise le modèle de données suivant : les différents moyens de transport (avion, train) sont déjà présents en base, et l'ajout de données concernera la table réservation et ses tables associées : Facture (one-to-one), Voyageur (one-to-many) et Transport (many-to-many).

Voici les temps mesurés lorsqu'on persiste traditionnellement les objets en base avec session.persist() (JPA : entityManager.persist()), avec 64 Mo de mémoire.

Total : 15 021 ms

On remarque que le flush est effectué une seule fois, à la fin du traitement et qu'il prend plus de 12 secondes à lui tout seul ! Cette méthode présente un inconvénient majeur. L'utilisation de la mémoire n'est pas maîtrisée et on risque une OutOfMemoryError. En effet, toutes les entités sont conservées dans le cache de niveau 1 d'Hibernate (la session) et ne sont supprimées qu'à la fin de la session.

Avec 48 Mo de mémoire, le même test échoue avec un beau OutOfMemoryError.

J'en profite pour faire un aparté sur le fonctionnement d'Hibernate. En interne, pour optimiser ses traitements (flush, regroupement d'instruction, etc.), Hibernate analyse régulièrement sa session et plus il y a d'objets dans la session, plus l'utilisation interne d'Hibernate est coûteuse.

Le test suivant montre les temps d'exécution du code précédant, alors que plusieurs milliers d'entités sont déjà présentes dans la session.

Total : 25 724 ms (25 792ms - 68ms)

Dans ce cas, le même code met 66% de temps en plus pour s'exécuter ! Cependant, la valeur n'est pas représentative du fait de l'interférence avec les autres facteurs du test et notamment la mémoire.

La méthode la plus simple pour remédier à ces problèmes est d'effectuer après chaque insertion un flush session.flush() et un nettoyage de la session session.clear().

Attention, le nettoyage de la session n'est possible que si aucun objet déjà présent en session n'est utilisé dans la suite du traitement. Pour ce genre de problème, il est possible d'utiliser session.evict() pour détacher un objet précis de la session. Voici les nouvelles mesures :

Total : 9 777 ms

On observe que le temps de flush et le temps d'insertion unitaire ont fortement diminué. Pour autant, il est possible d'optimiser encore le traitement en faisant des flush moins réguliers, par exemple toutes les 250 opérations unitaires, ce qui nous donne cette fois :

Total : 8 904 ms

On obtient donc un traitement de 8,9 s, soit un gain d'environ 40% par rapport au traitement initial.

Une autre façon d'optimiser le traitement est d'intervenir sur le FlushMode d'Hibernate.

Par défaut Hibernate flush de façon automatique, au moment qui lui semble opportun pour assurer le bon déroulement du traitement.

Il est possible de changer ce comportement par défaut :

• on peut désactiver le flush automatique et demander que le flush ne s'effectue qu'au commit de la transaction. Pour cela on indique à la session d'utiliser le mode de flush (FlushMode.COMMIT et en JPA FlushModeType.COMMIT) ;
• une autre solution est de désactiver complètement le flush automatique et d'indiquer à Hibernate que le flush sera effectué de façon manuelle, uniquement sur demande (FlushMode.MANUAL, pas d'équivalence en JPA).

Ces deux modes de flush optimisent les traitements en intervenant sur le fonctionnement interne d'Hibernate, car celui-ci ne vérifie plus l'état des objets en session pour savoir s'ils doivent être flushés ou non en fonction du type de requête traitée.

Attention, en changeant le mode de flush, vos modifications en cours ne sont pas persistées en base automatiquement, donc toutes les requêtes effectuées ramènent les valeurs en base. Il faut donc appeler le flush avant de lire des données en cours de modifications.

Avec le flush mode en MANUAL, on obtient les résultats suivants :

Total : 14 810 ms

Les résultats montrent très peu de différences, mais ceci est dû au traitement effectué. Dans notre traitement, il n'y a pas de lecture en base, opération qui demande à Hibernate de vérifier l'état de ses objets en session pour flusher si nécessaire. Les gains ne sont pas visibles dans ce test, mais existent réellement dans d'autres situations.

Hibernate propose également un type de session particulier, appelé session sans état (@@StatelessSession@) qui permet de manipuler les entités sans les rattacher à la session.

Ce type de session agit simplement comme une interface directe entre vos objets et votre base de données. Toutes les opérations effectuées (lecture, écriture) sont directement traitées et il n'est plus question de cache de niveau 1 et de problème mémoire.

Si ce type de session est rapide, il faut savoir qu'il y a des limitations à son utilisation. Premièrement, les objets chargés n'étant pas rattachés à la session, le mécanisme de chargement paresseux (lazy-loading) n'existe pas et ce n'est pas si mal quand on sait que c'est souvent une source de mauvaises performances dans ce type de traitement.

Le plus gros inconvénient de cette session est qu'elle ne gère pas les relations de type*ToMany lors de l'insertion de données. Il faut donc passer par une requête en SQL natif pour insérer des nouveaux enregistrements dans ces cas précis.

Note, pour les utilisateurs de JPA, la session sans état ne fait pas partie de la norme, il faudra appeler directement le code Hibernate.

Une fois cette présentation terminée, voyons les temps obtenus avec la session sans état :

Total : 8 214 ms

Les temps mesurés sont légèrement en dessous des meilleurs temps obtenus lors de l'utilisation de la session « classique », mais il faut dans notre cas passer par l'écriture de requêtes en SQL natif. Je dirai que l'utilisation de la session sans état est fortement conseillée si vous ne faites que de la lecture. Pour les traitements avec des insertions, cela dépend de la complexité de votre modèle de données et de votre besoin.