Il est important de mentionner que d'utiliser un paradigme session-par-operation est un anti-pattern. Autrement dit: n'ouvrez et ne fermez pas la Session à chacun de vos accès simples à la base de données dans un même thread! Bien sûr, le même raisonnement s'applique sur la gestion des transactions à la base de données. Les appels à la base de données devraient être faits en ordre et selon une séquence définie. Ils devraient également être regroupés en des unités de travail atomiques. (Notez que l?utilisation d?une connexion auto-commit constitue le même anti-pattern. Ce mode de fonctionnement existe pour les applications émettant des commandes SQL à partir d?une console. Hibernate désengage le mode auto-commit et s'attend à ce qu'un serveur d'applications le fasse également.) Les transactions avec la base de données ne sont jamais optionnelles, toute communication avec une base de données doit se dérouler dans une transaction, peu importe si vous lisez ou écrivez des données. Comme évoqué, le comportement auto-commit pour lire les données devrait être évité, puisque plusieurs petites transactions ne seront jamais aussi efficaces qu'une seule plus grosse clairement définie comme unité de travail. Ce dernier choix et en plus beaucoup plus facile a maintenir et à faire évoluer.

Le pattern d'utilisation le plus fréquemment rencontré dans des applications clients serveur multi-usagers est le session-per-request (littéralement : Session par requête). Dans ce modèle, la requête d'un client est envoyée à un serveur (Où la couche de persistance est implémentée via Hibernate), une nouvelle Session est ouverte et toutes les opérations d'accès à la base de données sont exécutées à l'intérieur de celle-ci. Lorsque le travail est terminé (et que les réponses à envoyer au client ont été préparées), la session est flushée et fermée. Une seule transaction à la base de données peut être utilisée pour répondre à la requête du client. La transaction est démarrée et validée au même moment où la Session est ouverte et fermée. La relation entre la Session et la Transaction est donc one-to-one. Ce modèle permet de répondre parfaitement aux attentes de la grande majorité des applications.

Le défi réside dans l'implémentation. Hibernate fournit une fonction de gestion de la "session courante" pour simplifier ce pattern. Tout ce que vous devez faire est démarrer une transaction lorsqu'une requête est traitée par le serveur, et la terminer avant que la réponse ne soit envoyée au client. Vous pouvez le faire de la manière que vous voulez, les solutions communes sont un ServletFilter, l'interception via AOP avec une pointcut sur les méthodes de type "service", ou un conteneur avec interception/proxy. Un conteneur EJB est un moyen standard d'implémenter ce genre d'acpect tranverse comme la démarcation des transactions sur les EJBs session, de manière déclarative avec CMT. Si vous décidez d'utiliser la démarcation programmatique des transactions, préferrez l'API Hibernate Transaction détaillée plus tard dans ce chapitre, afin de facilité l'utilisation et la portabilité du code.

Votre application peut accéder la "session courante" pour exécuter une requête en invoquant simplement sessionFactory.getCurrentSession() n'importe où et autant de fois que souhaité. Vous obtiendrez toujours une Session dont le scope est la transaction courante avec la base de données. Ceci doit être configuré soit dans les ressources local ou dans l'environnement JTA, voir Section 2.5, « Sessions Contextuelles ».

Il est parfois utile d'étendre le scope d'une Session et d'une transaction à la base de données jusqu'à ce que "la vue soit rendue". Ceci est particulièrement utile dans des applications à base de servlet qui utilisent une phase de rendue séparée une fois que la réponse a été préparée. Etendre la transaction avec la base de données jusqu'à la fin du rendering de la vue est aisé si vous implémentez votre propre intercepteur. Cependant, ce n'est pas facile si vous vous appuyez sur les EJBs avec CMT, puisqu'une transaction sera achevée au retour de la méthode EJB, avant le rendu de la vue. Rendez vous sur le site Hibernate et sur le forum pour des astuces et des exemples sur le pattern Open Session in View pattern..

Le paradigme session-per-request n'est pas le seul élément à utiliser dans le design de vos unités de travail. Plusieurs processus d'affaire requièrent toute une série d'interactions avec l'utilisateur, entrelacées d'accès à la base de donnée. Dans une application Web ou une application d'entreprise, il serait inacceptable que la durée de vie d'une transaction s'étale sur plusieurs interactions avec l'usager. Considérez l'exemple suivant:

Ceci s'appelle une unité de travail. Du point de vue de l'utilisateur: une conversation (ou transaction d'application). Il y a plusieurs façon de mettre ceci en place dans votre application.

Une première implémentation naïve pourrait consister à garder la Session et la transaction à la base de données ouvertes durant le temps de travail de l'usager, à maintenir les enregistrements verrouillés dans la base de données afin d'éviter des modifications concurrentes et de maintenir l'isolation et l'atomicité de la transaction de l'usager. Ceci est un anti-pattern à éviter, puisque le verrouillage des enregistrements dans la base de données ne permettrait pas à l'application de gérer un grand nombre d'usagers concurrents.

Il apparaît donc évident qu'il faille utiliser plusieurs transactions BDD afin d'implémenter la conversation. Dans ce cas, maintenir l'isolation des processus d'affaire devient partiellement la responsabilité de la couche applicative. Ainsi, la durée de vie d'une conversation devrait englober celle d'une ou de plusieurs transactions de base de données. Celle-ci sera atomique seulement si l'écriture des données mises à jour est faite exclusivement par la dernière transaction BDD la composant. Toutes les autres sous transactions BD ne doivent faire que la lecture de données. Ceci est relativement facile à mettre en place, surtout avec l'utilisation de certaines fonctionnalités d'Hibernate:

Les deux patterns session-per-request-with- detached- objects (session-par-requête-avec-objets- détachés) et session-per-conversation (session-par-conversation) ont chacun leurs avantages et désavantages qui seront exposés dans ce même chapitre, dans la section au sujet du contrôle optimiste de concurrence.

Une application peut accéder à la même entité persistante de manière concurrente dans deux Session s différentes. Toutefois, une instance d'une classe persistante n'est jamais partagée par deux instances distinctes de la classe Session . Il existe donc deux notions de l'identité d'un objet:

Ainsi, pour des objets attachés à une Session précise (dans la cadre d'exécution (scope) d'une instance de Session ), ces deux notions d'identité sont équivalentes et garanties par Hibernate. Par contre, si une application peut accéder de manière concurrente à la même entité persistante dans deux sessions différentes, les deux instances seront en fait différentes (en ce qui a trait à l'identité JVM). Les conflits sont résolus automatiquement par approche optimiste grâce au système de versionnage automatique lorsque Session.flush() ou Transaction.commit() est appelé.

Cette approche permet de reléguer à Hibernate et à la base de données sous-jacente le soin de gérer les problèmes d'accès concurrents. Cette manière de faire assure également une meilleure extensibilité de l'application puisque assurer l'identité JVM dans un thread ne nécessite pas de mécanismes de verrouillage coûteux ou d'autres dispositifs de synchronisation. Une application n'aura jamais le besoin de synchroniser des objets d'affaire tant qu'elle peut garantir qu'un seul thread aura accès à une instance de Session . Dans le cadre d'exécution d'un objet Session , l'application peut utiliser en toute sécurité == pour comparer des objets.

Une application qui utiliserait == à l'extérieur du cadre d'exécution d'une Session pourrait obtenir des résultats inattendus et causer certains effets de bords. Par exemple, si vous mettez 2 objets dans le même Set , ceux-ci pourraient avoir la même identité BD (i.e. ils représentent le même enregistrement), mais leur identité JVM pourrait être différente (elle ne peut, par définition, pas être garantie sur deux objets détachés). Le développeur doit donc redéfinir l'implémentation des méthodes equals() et hashcode() dans les classes persistantes et y adjoindre sa propre notion d'identité. Il existe toutefois une restriction: Il ne faut jamais utiliser uniquement l'identifiant de la base de données dans l'implémentation de l'égalité; Il faut utiliser une clé d'affaire, généralement une combinaison de plusieurs attributs uniques, si possible immuables. Les identifiants de base de données vont changer si un objet transitoire (transient) devient persistant. Si une instance transitoire est contenue dans un Set , changer le hashcode brisera le contrat du Set . Les attributs pour les clés d'affaire n'ont pas à être aussi stables que des clés primaires de bases de données. Il suffit simplement qu'elles soient stables tant et aussi longtemps que les objets sont dans le même Set . Veuillez consulter le site web Hibernate pour des discussions plus pointues à ce sujet. Notez que ce concept n'est pas propre à Hibernate mais bien général à l'implémentation de l'identité et de l'égalité en Java.

Bien qu'il puisse y avoir quelques rares exceptions à cette règle, il est recommandé de ne jamais utiliser les anti-patterns session-per- user-session et session-per-application . Vous trouverez ici- bas quelques problèmes que vous risquez de rencontrer si vous en faite l?utilisation. (Ces problèmes pourraient quand même survenir avec des patterns recommandés) Assurez-vous de bien comprendre les implications de chacun des patterns avant de prendre votre décision.

Si la couche de persistance Hibernate s'exécute dans un environnement non managé, les connexions à la base de données seront généralement prises en charge par le mécanisme de pool d'Hibernate. La gestion de la session et de la transaction se fera donc de la manière suivante:

// Non-managed environment idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
    tx = sess.beginTransaction();

    // do some work
    ...

    tx.commit();
}
catch (RuntimeException e) {
    if (tx != null) tx.rollback();
    throw e; // or display error message
}
finally {
    sess.close();
}

Vous n'avez pas à invoquer flush() explicitement sur la Session - l'appel de commit() déclenchera automatiquement la synchronisation (selon le Section 10.10, « Flush de la session » de la session. Un appel à close() marque la fin de la session. La conséquence directe est que la connexion à la base de données sera relachée par la session. Ce code est portable est fonctionne dans les environnements non managé ET les environnements JTA.

Une solution plus flexible est la gestion par contexte fourni par Hibernate que nous avons déjà rencontré:

// Non-managed environment idiom with getCurrentSession()
try {
    factory.getCurrentSession().beginTransaction();

    // do some work
    ...

    factory.getCurrentSession().getTransaction().commit();
}
catch (RuntimeException e) {
    factory.getCurrentSession().getTransaction().rollback();
    throw e; // or display error message
}

Vous ne verrez probablement jamais ces exemples de code dans les applications; les exceptions fatales (exceptions du système) ne devraient être traitées que dans la couche la plus "haute". En d'autres termes, le code qui exécute les appels à Hibernate (à la couche de persistance) et le code qui gère les RuntimeException (qui ne peut généralement effectuer qu'un nettoyage et une sortie) sont dans des couches différentes. La gestion du contexte courant par Hibernate peut simplifier notablement ce design, puisque vous devez accéder à la gestion des exceptions de la SessionFactory, ce qui est décrit plus tard dans ce chapitre.

Notez que vous devriez sélectionner org.hibernate.transaction.JDBCTransactionFactory (le défaut), pour le second exemple "thread" comme hibernate.current_session_context_class.

Si votre couche de persistance s'exécute dans un serveur d'application (par exemple, derrière un EJB Session Bean), toutes les datasource utilisées par Hibernate feront automatiquement partie de transactions JTA globales. Hibernate propose deux stratégies pour réussir cette intégration.

Si vous utilisez des transactions gérées par un EJB (bean managed transactions - BMT), Hibernate informera le serveur d'application du début et de la fin des transactions si vous utilisez l'API Transaction . Ainsi, le code de gestion des transactions sera identique dans les deux types d'environnements.

// BMT idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
    tx = sess.beginTransaction();

    // do some work
    ...

    tx.commit();
}
catch (RuntimeException e) {
    if (tx != null) tx.rollback();
    throw e; // or display error message
}
finally {
    sess.close();
}

Si vous souhaitez utiliser une Session couplée à la transaction, c'est à dire, utiliser la fonctionnalité getCurrentSession() pour la propagation facile du contexte, vous devrez utiliser l'API JTA UserTransaction directement:

// BMT idiom with getCurrentSession()
try {
    UserTransaction tx = (UserTransaction)new InitialContext()
                            .lookup("java:comp/UserTransaction");

    tx.begin();

    // Do some work on Session bound to transaction
    factory.getCurrentSession().load(...);
    factory.getCurrentSession().persist(...);

    tx.commit();
}
catch (RuntimeException e) {
    tx.rollback();
    throw e; // or display error message
}

Avec CMT, la démarcation des transactions est faite dans les descripteurs de déploiement des Beans Sessions et non de manière programmmatique, ceci réduit le code:

// CMT idiom
 Session sess = factory.getCurrentSession();

 // do some work
 ...

Dans un EJB CMT même le rollback intervient automatiquement, puisqu'une RuntimeException non traitée et soulevée par une méthode d'un bean session indique au conteneur d'annuler la transaction globale. Ceci veut donc dire que vous n'avez pas à utiliser l'API Transaction d'Hibernate dans CMT.

Notez que le fichier de configuration Hibernate devrait contenir les valeurs org.hibernate.transaction.JTATransactionFactory dans un environnement BMT ou org.hibernate.transaction.CMTTransactionFactory dans un environnement CMT là où vous configurez votre transaction factory Hibernate. N'oubliez pas non plus de spécifier le paramètre org.hibernate.transaction.manager_lookup_class . De plus, assurez vous de fixez votre hibernate.current_session_context_class soit à "jta" ou de ne pas le configurer (compatibilité avec les versions précédentes).

La méthode getCurrentSession() a un inconvénient dans les environnement JTA. Il y a une astuce qui est d'utiliser un mode de libération de connexion after_statement , qui est alors utilisé par défaut. Du à une étrange limitation de la spec JTA, il n'est pas possible pour Hibernate de nettoyer et ferme automatiquement un ScrollableResults ouvert ou une instance d'Iterator retournés scroll() ou iterate(). Vous devez libérer le curseur base de données sous jacent ou invoquer Hibernate.close(Iterator) explicitement depuis un bloc finally. (Bien sur, la plupart des applications peuvent éviter d'uiliser scroll() ou iterate() dans un code CMT.)

Si une Session lance une exception (incluant les exceptions du type SQLException ou d'un sous-type), vous devez immédiatement faire le rollback de la transaction, appeler Session.close() et relâcher les références sur l'objet Session . La Session contient des méthodes pouvant la mettre dans un état inutilisable. Vous devez considérer qu'aucune exception lancée par Hibernate n'est traitable. Assurez-vous de fermer la session en faisant l'appel à close() dans un bloc finally .

L'exception HibernateException , qui englobe la plupart des exceptions pouvant survenir dans la couche de persistance Hibernate, est une exception non vérifiée (Ceci n'était pas le cas dans certaines versions antérieures de Hibernate.) Il est de notre avis que nous ne devrions pas forcer un développeur à gérer une exception qu'il ne peut de toute façon pas traiter dans une couche technique. Dans la plupart des applications, les exceptions non vérifiées et les exceptions fatales sont gérées en amont du processus (dans les couches hautes) et un message d'erreur est alors affiché à l'usager (ou un traitement alternatif est invoqué.) Veuillez noter qu'Hibernate peut également lancer des exceptions non vérifiées d'un autre type que HibernateException . Celles-ci sont également non traitables et vous devez les traiter comme telles.

Hibernate englobe les SQLException s lancées lors des interactions directes avec la base de données dans des exceptions de type: JDBCException . En fait, Hibernate essaiera de convertir l'exception dans un sous-type plus significatif de JDBCException . L'exception SQLException sous-jacente est toujours disponible via la méthode JDBCException.getCause() . Cette conversion est faite par un objet de type SQLExceptionConverter , qui est rattaché à l'objet SessionFactory . Par défaut, le SQLExceptionConverter est associé au dialecte de BD configuré dans Hibernate. Toutefois, il est possible de fournir sa propre implémentation de l'interface. (Veuillez vous référer à la javadoc sur la classe SQLExceptionConverterFactory pour plus de détails. Les sous-types standard de JDBCException sont:

L'un des avantages fournis par les environnements transactionnels JTA (tels les containers EJB) est la gestion du timeout de transaction. La gestion des dépassements de temps de transaction vise à s'assurer qu'une transaction agissant incorrectement ne viendra pas bloquer indéfiniment les ressources de l'application. Hibernate ne peut fournir cette fonctionnalité dans un environnement transactionnel non-JTA. Par contre, Hibernate gère les opérations d'accès aux données en allouant un temps maximal aux requêtes pour s'exécuter. Ainsi, une requête créant de l'inter blocage ou retournant de très grandes quantités d'information pourrait être interrompue. Dans un environnement transactionnel JTA, Hibernate peut déléguer au gestionnaire de transaction le soin de gérer les dépassements de temps. Cette fonctionnalité est abstraite par l'objet Transaction .

        Session sess = factory.openSession();
        try {
            //mettre le timeout à 3 secondes.
            sess.getTransaction().setTimeout(3);
            sess.getTransaction().begin();

            // Effectuer le travail ...

            sess.getTransaction().commit()
        }
        catch (RuntimeException e) {
            if ( sess.getTransaction().isActive() ) {
                sess.getTransaction().rollback();
            }
            throw e;
            // ou afficher le message d'erreur.
        }
        finally {
            sess.close();
        }

Notez que setTimeout() ne peut pas être appelé d'un EJB CMT, puisque le timeout des transaction doit être spécifié de manière déclarative.

Dans cet exemple d'implémentation utilisant peu les fonctionnalités d'Hibernate, chaque interaction avec la base de données se fait en utilisant une nouvelle Session et le développeur doit recharger les données persistantes à partir de la BD avant de les manipuler. Cette implémentation force l'application à vérifier la version des objets afin de maintenir l'isolation transactionnelle. Cette approche, semblable à celle retrouvée pour les EJB, est la moins efficace de celles présentées dans ce chapitre.

            // foo est une instance chargée antérieurement par une autre
            Session session = factory.openSession();
            Transaction t = session.beginTransaction();

            int oldVersion = foo.getVersion();
            session.load( foo, foo.getKey() ); // Charger l'état courant

            if ( oldVersion!=foo.getVersion )
                throw new StaleObjectStateException();

            foo.setProperty("bar");
            t.commit();
            session.close();

Le mapping de la propriété version est fait via <version> et Hibernate l'incrémentera automatiquement à chaque flush() si l'entité doit être mise à jour.

Bien sûr, si votre application ne fait pas face à beaucoup d'accès concurrents et ne nécessite pas l'utilisation du versionnage, cette approche peut également être utilisée, il n'y a qu'à ignorer le code relié au versionnage. Dans ce cas, la stratégie du last commit wins (littéralement: le dernier commit l'emporte) sera utilisée pour les conversations (longues transactions applicatives). Gardez à l'esprit que cette approche pourrait rendre perplexe les utilisateurs de l'application car ils pourraient perdre des données mises à jour sans qu'aucun message d'erreur ne leur soit présenté et sans avoir la possibilité de fusionner les données.

Il est clair que la gestion manuelle de la vérification du versionnage des objets ne peut être effectuée que dans certains cas triviaux et que cette approche n'est pas valable pour la plupart des applications. De manière générale, les applications ne cherchent pas à actualiser de simples objets sans relations, elles le font généralement pour de larges graphes d'objets. Pour toute application utilisant le paradigme des conversations ou des objets détachés, Hibernate peut gérer automatiquement la vérification des versions d'objets.

Dans ce scénario, une seule instance de Session et des objets persistants est utilisée pour toute l'application. Hibernate vérifie la version des objets persistants avant d'effectuer le flush() et lance une exception si une modification concurrente est détectée. Il appartient alors au développeur de gérer l'exception. Les traitements alternatifs généralement proposés sont alors de permettre à l'usager de faire la fusion des données ou de lui offrir de recommencer son travail à partie des données les plus récentes dans la BD.

Il est à noter que lorsqu'une application est en attente d'une action de la part de l?usager, La Session n'est pas connectée à la couche JDBC sous-jacente. C'est la manière la plus efficace de gérer les accès à la base de données. L'application ne devrait pas se préoccuper du versionnage des objets, de la réassociation des objets détachés, ni du rechargement de tous les objets à chaque transaction.

            // foo est une instance chargée antérieurement par une autre session

            session.reconnect();// Obtention d'une nouvelle connexion JDBC
            Transaction t = session.beginTransaction();
            foo.setProperty("bar");
            t.commit(); //Terminer la transaction, propager les changements et vérifier les versions.
            session.disconnect(); // Retourner la connexion JDBC
            

L'objet foo sait quel objet Session l'a chargé. Session.reconnect() obtient une nouvelle connexion (celle-ci peut être également fournie) et permet à la session de continuer son travail. La méthode Session.disconnect() déconnecte la session de la connexion JDBC et retourne celle-ci au pool de connexion (à moins que vous ne lui ayez fourni vous même la connexion.) Après la reconnexion, afin de forcer la vérification du versionnage de certaines entités que vous ne cherchez pas à actualiser, vous pouvez faire un appel à Session.lock() en mode LockMode.READ pour tout objet ayant pu être modifié par une autre transaction. Il n'est pas nécessaire de verrouiller les données que vous désirez mettre à jour.

Si des appels implicites aux méthodes disconnect() et reconnect() sont trop coûteux, vous pouvez les éviter en utilisant hibernate.connection.release_mode .

Ce pattern peut présenter des problèmes si la Session est trop volumineuse pour être stockée entre les actions de l'usager. Plus spécifiquement, une session HttpSession se doit d'être la plus petite possible. Puisque la Session joue obligatoirement le rôle de mémoire cache de premier niveau et contient à ce titre tous les objets chargés, il est préférable de n'utiliser cette stratégie que pour quelques cycles de requêtes car les objets risquent d'y être rapidement périmés.

Notez que la Session déconnectée devrait être conservée près de la couche de persistance. Autrement dit, utilisez un EJB stateful pour conserver la Session et évitez de la sérialiser et de la transférer à la couche de présentation (i.e. Il est préférable de ne pas la conserver dans la session HttpSession .)

Chaque interaction avec le système de persistance se fait via une nouvelle Session . Toutefois, les mêmes instances d'objets persistants sont réutilisées pour chacune de ces interactions. L'application doit pouvoir manipuler l'état des instances détachées ayant été chargées antérieurement via une autre session. Pour ce faire, ces objets persistants doivent être rattachés à la Session courante en utilisant Session.update() , Session.saveOrUpdate() , ou Session.merge() .

            // foo est une instance chargée antérieurement par une autre session

            foo.setProperty("bar");
            session = factory.openSession();
            Transaction t = session.beginTransaction();
            session.saveOrUpdate(foo);  //Utiliser merge() si "foo" pourrait avoir été chargé précédement
            t.commit();
            session.close(); 

Encore une fois, Hibernate vérifiera la version des instances devant être actualisées durant le flush(). Une exception sera lancée si des conflits sont détectés.

Vous pouvez également utiliser lock() au lieu de update() et utiliser le mode LockMode.READ (qui lancera une vérification de version, en ignorant tous les niveaux de mémoire cache) si vous êtes certain que l'objet n'a pas été modifié.

Vous pouvez désactiver l'incrémentation automatique du numéro de version de certains attributs et collections en mettant la valeur du paramètre de mapping optimistic-lock à false. Hibernate cessera ainsi d'incrémenter leur numéro de version s'ils sont mis à jour.

Certaines entreprises possèdent de vieux systèmes dont les schémas de bases de données sont statiques et ne peuvent être modifiés. Il existe aussi des cas où plusieurs applications doivent accéder à la même base de données, mais certaines d'entre elles ne peuvent gérer les numéros de version ou les champs horodatés. Dans les deux cas, le versionnage ne peut être implanté par le rajout d'une colonne dans la base de données. Afin de forcer la vérification de version dans un système sans en faire le mapping, mais en forçant une comparaison des états de tous les attributs d'une entité, vous pouvez utiliser l'attribut optimistic- lock="all" sous l'élément <class> . Veuillez noter que cette manière de gérer le versionnage ne peut être utilisée que si l'application utilises de longues sessions, lui permettant de comparer l'ancien état et le nouvel état d'une entité. L'utilisation d'un pattern session-per-request-with-detached- objects devient alors impossible.

Il peut être souhaitable de permettre les modifications concurrentes lorsque des champs distincts sont modifiés. En mettant la propriété optimistic-lock="dirty" dans l'élément <class> , Hibernate ne fera la comparaison que des champs devant être actualisés lors du flush().

Dans les deux cas: en utilisant une colonne de version/horodatée ou via la comparaison de l'état complet de l'objet ou de ses champs modifiés, Hibernate ne créera qu'une seule commande d'UPDATE par entité avec la clause WHERE appropriée pour mettre à jour l'entité ET en vérifier la version. Si vous utilisez la persistance transitive pour propager l'évènement de rattachement à des entités associées, il est possible qu'Hibernate génère des commandes d'UPDATE inutiles. Ceci n'est généralement pas un problème, mais certains déclencheurs on update dans la base de données pourraient être activés même si aucun changement n'était réellement persisté sur des objets associés. Vous pouvez personnaliser ce comportement en indiquant select-before- update="true" dans l'élément de mapping <class> . Ceci forcera Hibernate à faire le SELECT de l'instance afin de s'assurer que l'entité doit réellement être actualisée avant de lancer la commande d'UPDATE.