Verrouillage optimiste dans Spring Boot

Aperçu

Nous savons que pour les applications logicielles à grande échelle qui gèrent un grand nombre de transactions de base de données, la mise en œuvre d’un mécanisme de gestion de la concurrence est essentielle afin que nous puissions gérer plusieurs appels de base de données simultanément et efficacement sans aucune perte de données..

L’un des moyens d’implémenter le contrôle de la concurrence est le verrouillage optimiste mécanisme fourni par API de persistance Java.

Contrairement au verrouillage pessimiste, le verrouillage optimiste n’applique pas de verrous sur la base de données et réduit donc le niveau d’isolement du système et augmente la capacité de débit du logiciel. De plus, il n’y a aucune chance d’impasse dans ce cas comme dans le verrouillage pessimiste.

Il permet aux conflits transactionnels de se produire et les détecte lors de la validation de la transaction, puis nous pouvons gérer le flux en fonction de notre cas d’utilisation.

Implémentation du verrouillage optimiste

La mise en œuvre du verrouillage optimiste est simple. Il peut être implémenté en utilisant une nouvelle propriété version dans l’entité (en l’annotant avec @Version). Bien qu’il y ait eu plusieurs implémentations de cet attribut, la plus efficace et la plus largement utilisée est une simple version de type compteur numérique de type entier dont la valeur sera auto-incrémentée chaque fois que nous mettrons à jour les données. Nous devons également nous assurer que l’état de l’entité n’est pas extrait du cache pour cela.

Essayons de comprendre l’utilisation de l’attribut version.

1) L’investisseur1 et l’investisseur2 récupèreront les mêmes données avec, disons, version=1,

2) l’investisseur1 sera enregistré en premier et la version sera automatiquement mise à jour vers 2(vesrion=version+1).

3) maintenant, lorsque nous essayons de sauvegarder l’investisseur2, la requête similaire à la requête suivante sera exécutée

Mettre à jour l’investisseur

Définir version=2, firstName=’XYZ’

Où uuid=randomUuid

et versions=1

4) maintenant, comme nous le savons, cette version est déjà mise à jour par l’investisseur1 lors de l’enregistrement, donc aucune ligne ne sera récupérée lors de la mise à jour de l’investisseur2, et optimisticLockingExceptionoptimisticLockingException sera lancée pour l’investisseur2, empêchant ainsi la perte de données silencieuse de l’investisseur1.

Gestion de optimisticLockingException :

Il existe principalement deux façons de gérer cette exception :

1) Dans le bloc catch, nous pouvons récupérer à nouveau les données pour investor2, puis essayer d’apporter des modifications aux données si possible, puis réessayer de sauvegarder les données.

2) La deuxième option pourrait être que nous montrons simplement un message à l’utilisateur indiquant qu’un autre utilisateur a mis à jour les données ou qu’une erreur s’est produite et demandons à l’utilisateur de mettre à jour les données à nouveau.

Ainsi, selon nos cas d’utilisation, nous pouvons implémenter l’une ou l’autre des méthodes ci-dessus.

Conclusion

Bien que le verrouillage optimiste ne puisse pas être implémenté pour gérer tous les types de problèmes de concurrence, l’implémentation du verrouillage optimiste dépend du cas par cas. Par exemple, il peut être utilisé lorsqu’il y a plus de transactions lues que de transactions écrites. Il peut être utilisé lorsque nous ne voulons pas qu’une seule transaction acquière le verrou sur une base de données ou, en fait, lorsque nous pouvons nous permettre de perdre des données. De plus, comme dans le verrouillage pessimiste, il ne verrouille pas les données, il peut donc être utilisé lorsque nous mettons les données dans un état détaché après les avoir récupérées, mais en même temps, il va sans dire que le verrouillage pessimiste fournit plus de données intégrité.

TROUVÉ CELA UTILE ? PARTAGEZ-LE