Quand utiliser la concurrence pessimiste?

Question

Quels sont les scénarios spécifiques où la concurrence pessimiste est utilisée?

Answer 1

Qu'entendez-vous exactement par "quand utiliser le verrouillage par pess"?

Si vous traitez des données gérées par SGBD, vous n'avez aucune option. Le SGBD l'utilise à chaque mise à jour, point final, car le SGBD lui-même n'a pas d'option s'il veut assurer l'intégrité des données.

Même les systèmes basés sur MVCC (? Tels que Oracle) ne possèdent pas d'autre choix que de sérialisation activités à l'aide de verrouillage 2 phases pour traiter correctement les cas tels que:

TX A démarre, TX B commence; TX A insère l'ID 1; TX B insère l'ID 1; TX A vérifie les contraintes; TX B vérifie les contraintes; TX A commet; TX B s'engage.

Si la vérification de contrainte de A/B était autorisée à ignorer l'insertion du même ID effectué par B/A, la base de données finirait par violer la clé. Il est préférable que les verrous contrôlés par l'application ne soient pessimistes que si vous pouvez être sûr qu'ils ne seront pas laissés en attente pendant que l'utilisateur doit taper quelque entrée (ou pendant que toute activité est effectuée qui peut causer retards). Mais c'est une réponse à la question inverse, "quand ne pas l'utiliser".

EDIT

Une indication pour « Quand l'utiliser » pourrait être que dans des situations de haute contention, vous voulez « fail-rapide » pour la transaction selon « arrive en deuxième position ». Cela vous assure que les transactions qui ne peuvent pas être complétées n'accapareront pas trop de ressources, et que ces ressources sont disponibles pour une exécution plus rapide (et donc aussi une libération plus rapide) de la transaction "arrivée en premier". Réalisez, cependant, que vous augmentez vos chances de tomber dans des blocages, et puisque les verrous sont contrôlés par l'application, c'est à vous de résoudre tout blocage.

Answer 2

Oui, quand vous ne pouvez absolument pas avoir deux personnes qui modifient le même enregistrement en même temps. Les banques le font le plus.

Answer 3

La simultanéité pessimiste devrait probablement être utilisée dans les situations où les tentatives d'édition simultanée se produisent fréquemment, et non comme des cas exceptionnels. La simultanéité optimiste peut provoquer des résultats discordants pour les utilisateurs lorsqu'ils sont informés que leurs modifications ne seront pas enregistrées. Il convient donc de l'éviter lorsqu'il s'agit d'une occurrence normale.