First, let's define a unit of work. A unit of work is a design pattern described by Martin Fowler as «  [maintaining] a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.  »[PoEAA] In other words, its a series of operations we wish to carry out against the database together. Basically, it is a transaction, though fulfilling a unit of work will often span multiple physical database transactions (see Section 12.1.2, « Longue conversation »). So really we are talking about a more abstract notion of a transaction. The term "business transaction" is also sometimes used in lieu of unit of work.

Tout d'abord n'utilisez pas l'anti-pattern session-par-operation et n'ouvrez et ne fermez pas la Session à chacun de vos accès simples à la base de données dans un même thread ! Par conséquent, le même raisonnement est applicable à la gestion des transactions dans la base de données. Dans une application, les appels à la base de données doivent être effectués selon une séquence ordonnée et sont regroupés en unités de travail atomiques. (Notez que l'utilisation d'une connexion auto-commit après chaque déclaration SQL est inutile dans une application. Ce mode de fonctionnement existe pour les applications émettant des commandes SQL ad-hoc à 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 déjà mentionné, 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 est de plus beaucoup plus facile à maintenir et plus extensible.

Le modèle d'utilisation le plus fréquemment rencontré dans des applications clients serveur multi-usagers est la session-par-requête. Dans ce modèle, la requête d'un client est envoyée au serveur (où la couche de persistance est implémentée via Hibernate), une nouvelle Session Hibernate 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 un-à-un. Cette relation entre les deux est un-à-un et 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 intégrée de la "session courante" pour simplifier ce pattern. Il vous suffit de 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 choisir la manière de l'effectuer, les solutions communes sont un ServletFilter, l'interception via AOP avec une coupe transverse (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 transverse comme la démarcation des transactions sur les EJB 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 traitée plus tard dans ce chapitre, afin de faciliter l'utilisation et la portabilité du code.

Your application code can access a "current session" to process the request by calling sessionFactory.getCurrentSession(). You will always get a Session scoped to the current database transaction. This has to be configured for either resource-local or JTA environments, see Section 2.5, « Sessions contextuelles  ».

Il est parfois utile d'étendre la portée 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. Étendre 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 EJB 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 .

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 Sessionparticulière (c'est-à-dire dans la portée d'une instance de Session), ces deux notions d'identité sont équivalentes et l'identité JVM pour l'identité de la base de données sont garanties par Hibernate. Cependant, alors qu'une application peut accéder de manière concurrente au "même" objet métier (identité 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 au moment du flush/sauvegarde.

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 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. Par exemple, si vous mettez deux objets dans le même Set , ceux-ci pourraient avoir la même identité de base de données (c'est-à-dire 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 (en général avec des instances dégachées) 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-modèles session-par- utilisateur-session ou session-par-application . Notez que certains des problèmes suivants pourraient néanmoins survenir avec des modèles recommandés, assurez-vous de bien comprendre les implications de chacun des modèles avant de prendre une décision concernant votre design :

Si la couche de persistance Hibernate s'exécute dans un environnement non géré, les connexions à la base de données seront généralement prises en charge par le mécanisme de pool d'Hibernate qui obtient les connexions. 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();

}

You do not have to flush() the Session explicitly: the call to commit() automatically triggers the synchronization depending on the FlushMode for the session. A call to close() marks the end of a session. The main implication of close() is that the JDBC connection will be relinquished by the session. This Java code is portable and runs in both non-managed and JTA environments.

Une solution plus flexible est la gestion par contexte de la session courante intégrée, fournie par Hibernate que nous avons déjà rencontrée :

// 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, puisqu'il vous suffit d'accéder à la SessionFactory. La gestion des exceptions est traitée plus loin dans ce chapitre.

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

Si votre couche de persistance s'exécute dans un serveur d'applications (par exemple, derrière un EJB Session Bean), toutes les datasources utilisées par Hibernate feront automatiquement partie de transactions JTA globales. Vous pouvez également installer une implémentation autonome JTA et l'utiliser sans l'EJB.Hibernate propose deux stratégies pour réussir l'intégration JTA.

Si vous utilisez des transactions gérées par un EJB (bean managed transactions - BMT), Hibernate informera le serveur d'applications 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 environnements non gérés.

// 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 devez 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 programmatique, par conséquent le code est réduit à :

// CMT idiom

 Session sess = factory.getCurrentSession();


 // do some work

 ...

Dans un EJB CMT, le rollback aussi 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 de Hibernate dans CMT ou BMT et vous obtenez la propagation automatique de la session courante liée à la transaction.

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 fabrique de transaction Hibernate. N'oubliez pas non plus de spécifier le paramètre org.hibernate.transaction.manager_lookup_class . De plus, assurez vous de fixer 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 environnements 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 à Hibernate de nettoyer 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'utiliser scroll() ou iterate() dans un code JTA ou CMT.)

Si une Session lance une exception (incluant les exceptions du type SQLException ou d'un sous-type), vous devez immédiatement effectuer 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 comme recouvrable. Assurez-vous de fermer la session en appelant 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 des versions antérieures de Hibernate.) Nous pensons 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 systèmes, 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 que 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(). Hibernate convertit le SQLExceptionConverter en une sous-classe JDBCException, en utilisant le SQLExceptionConverter qui est rattaché à l'objet SessionFactory. Par défaut, le SQLExceptionConverter est défini par le dialecte 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 :

Une des caractéristiques extrêmement importante fournie dans les environnements gérés tels les EJB, est la gestion du timeout de transaction qui n'est jamais fournie pour le code non géré. 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 et ne retourner aucune réponse à l'utilisateur. 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'informations pourrait être interrompue. Dans un environnement géré, Hibernate peut déléguer au gestionnaire de transaction JTA, le soin de gérer les dépassements de temps. Cette fonctionnalité est abstraite par l'objet Transaction.

Session sess = factory.openSession();

try {

    //set transaction timeout to 3 seconds

    sess.getTransaction().setTimeout(3);

    sess.getTransaction().begin();


    // do some work

    ...


    sess.getTransaction().commit()

}

catch (RuntimeException e) {

    sess.getTransaction().rollback();

    throw e; // or display error message

}

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 de 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 base de données 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 parmi celles qui sont présentées dans ce chapitre.

// foo is an instance loaded by a previous Session

session = factory.openSession();

Transaction t = session.beginTransaction();


int oldVersion = foo.getVersion();

session.load( foo, foo.getKey() ); // load the current state

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

foo.setProperty("bar");


t.commit();

session.close();

Le mappage 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. Hibernate peut gérer automatiquement la vérification des versions d'objets en utilisant soit une Session longue, soit des instances détachées comme paradigme des conversations.

Dans ce scénario, une seule instance de Session et des objets persistants est utilisée pour toute la conversation, connue sous session-par-conversation. 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 base de données.

Notez 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, ou du rattachement des objets détachés, ni du rechargement de tous les objets à chaque transaction.

// foo is an instance loaded earlier by the old session

Transaction t = session.beginTransaction(); // Obtain a new JDBC connection, start transaction


foo.setProperty("bar");


session.flush();    // Only for last transaction in conversation

t.commit();         // Also return JDBC connection

session.close();    // Only for last transaction in conversation

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. En général, vous configurerezFlushMode.NEVER sur une Session étendue, de façon que seul le dernier cycle de transaction de la base de données puissent persister toutes les modifications effectuées dans cette conversation. Par conséquent, cette dernière transaction inclura l'opération flush(), de même que close() la session pour finir la conversation.

Ce modèle 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 une Session que pour une seule conversation, 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 dans un environnement 3 niveaux et évitez de la sérialiser et de la transférer à la couche de présentation (c'est-à-dire qu'il est préférable de ne pas la conserver dans la session HttpSession .)

Le modèle de session étendue, ou session-par-conversation, est plus difficile à implémenter avec la gestion automatique de contexte de session courante. À cet effet, vous devez fournir votre propre implémentation deCurrentSessionContext, pour des exemples consultez Hibernate Wiki.

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 is an instance loaded by a previous Session

foo.setProperty("bar");

session = factory.openSession();

Transaction t = session.beginTransaction();

session.saveOrUpdate(foo); // Use merge() if "foo" might have been loaded already

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 si la propriété est dirty.

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 se fier à une colonne particulière dans une table. Afin de forcer la vérification de version dans un système sans en faire le mappage, mais en forçant une comparaison des états de tous les attributs d'une entité, vous pouvez utiliser l'attribut optimistic- lock="all" dans le mappage <class>. Veuillez noter que cette manière de gérer le versionnage ne peut être utilisée que si l'application utilise de longues sessions, lui permettant de comparer l'ancien état et le nouvel état d'une entité. L'utilisation d'un modèle session-per-request-with-detached- objects devient alors impossible.

Il peut être souhaitable de permettre les modifications concurrentes du moment que les modifications ne se chevauchent pas. En configurant la propriété à optimistic-lock="dirty" quand vous mappez le <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 UPDATE par entité avec la clause WHERE appropriée pour vérifier la version et mettre à jour les informations. Si vous utilisez la persistance transitive pour propager l'évènement de rattachement à des entités associées, il est possible que Hibernate génère des commandes de mise à jour 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 détachés. Vous pouvez personnaliser ce comportement en indiquant select-before- update="true" dans l'élément de mappage <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 de mise à jour de l'enregistrement.