Il semble que vous ayez configuré Hibernate pour utiliser contrôle de concurrence optimiste . Cela signifie que votre table User a un champ de version qu'Hibernate incrémente à chaque mise à jour de ligne.
Très probablement, votre transaction commence au début de la requête HTTP et se termine à la fin de la réponse HTTP. Cela signifie que le processus de modification d'un utilisateur consiste en deux transactions :une transaction pour remplir le formulaire Web et une transaction pour enregistrer les modifications.
Dans ce cas, changer le niveau d'isolement de la base de données ne servira à rien. Très probablement, tout ce que vous obtiendrez est moins bonnes performances et évolutivité .
Ce n'est pas une mauvaise chose d'avoir StaleObjectException s. Cela reflète le monde réel - les gens travaillent effectivement sur la même chose de temps en temps et des conflits peuvent survenir. La question est la suivante :lorsqu'un conflit a été détecté, comment le résolvez-vous de manière satisfaisante pour les utilisateurs finaux ? Peut-il être résolu sans l'aide de l'utilisateur ?
Les stratégies possibles pourraient être de
-
écraser les modifications de l'utilisateur précédent (souvent pas ce que vous voulez - d'où la nécessité d'un contrôle de la concurrence),
-
afficher un message d'erreur demandant à l'utilisateur d'actualiser et d'effectuer à nouveau ses modifications,
-
fusionne automatiquement les modifications sans écraser les modifications de l'utilisateur précédent (parfois possible)
-
informer l'utilisateur de l'obsolescence de ses données et lui proposer un moyen de fusionner manuellement ses modifications
Tout dépend du contexte.
