Quelqu'un peut-il m'expliquer si nous utilisons Spring pour la gestion des transactions, comment les mises à jour simultanées seront gérées par hibernate (Gestion automatique des versions en mémoire d'hibernate) ou je dois mettre la colonne de version dans la base de données pour prendre soin des mises à jour simultanées manuellement.
Que vous utilisiez ou non Spring pour la gestion des transactions n'a pas vraiment d'importance et n'est pas pertinent en ce qui concerne la gestion de la concurrence, cela est en fait géré par Hibernate. Hibernate peut utiliser 2 stratégies pour gérer les mises à jour simultanées :le verrouillage optimiste et le verrouillage pessimiste.
Optimiste
Lorsque vous utilisez le verrouillage optimiste, vous mappez un attribut spécial (un nombre, un horodatage) en tant que version (donc vous avez en fait une colonne pour cela). Cette version est lue lorsque vous récupérez une entité et incluse dans la clause where lors d'une mise à jour et incrémenté par Hiberner.
Pour illustrer comment cela fonctionne, imaginons que vous chargez une entité Person avec id=1 et avec une version actuelle=1. Après une sauvegarde, Hibernate effectuera quelque chose comme ceci :
update PERSON set ID=1, NAME='NAME 1', VERSION=2 where ID=1 and VERSION=1;
Alors, maintenant, imaginez que vous avez deux transactions simultanées en cours d'exécution, chacune chargeant la même entité (même numéro de version) et en changeant le nom.
Supposons que la transaction #1 soit validée en premier, la requête suivante est effectuée :
update PERSON set ID=1, NAME='NAME 1', VERSION=2 where ID=1 and VERSION=1;
Il réussit et la version est incrémentée.
Ensuite la transaction #2 est validée, la requête suivante est effectuée :
update PERSON set ID=1, NAME='NAME 2', VERSION=2 where ID=1 and VERSION=1;
Celui-ci ne mettra rien à jour car la clause where ne correspondra à aucun enregistrement. C'est là que vous obtiendrez une exception de concurrence optimiste.
Cette stratégie est appropriée lorsque vous ne maintenez pas la connexion, lorsque les accès simultanés ne sont pas fréquents et s'adapte très bien. Et tout est bien sûr géré de manière transparente par Hibernate pour vous, tant que vous mappez un attribut de version.
Pessimiste
Lors de l'utilisation du verrouillage pessimiste, Hibernate verrouille un enregistrement pour votre usage exclusif jusqu'à ce que vous en ayez fini (généralement en utilisant un SELECT ... FOR UPDATE ). Toute autre transaction simultanée tentant d'accéder au même enregistrement sera suspendue jusqu'à ce que le verrou soit supprimé. Cette stratégie offre une meilleure prévisibilité, au prix de la performance et n'évolue pas indéfiniment.
Références
- Guide de référence Hibernate Core
- 11.3. Contrôle de concurrence optimiste
- 11.4. Verrouillage pessimiste
