Verrouillage optimiste ou pessimiste
Je comprends les différences entre le verrouillage optimiste et le verrouillage pessimiste. Maintenant, quelqu'un pourrait-il m'expliquer quand j'utiliserais l'un ou l'autre en général?
Et la réponse à cette question change-t-elle selon que j'utilise ou non une procédure stockée pour effectuer la requête?
Mais juste pour vérifier, optimiste signifie "ne verrouille pas la table pendant la lecture" et pessimiste signifie "verrouille la table pendant la lecture".
Optimistic Locking est une stratégie dans laquelle vous lisez un enregistrement, notez le numéro de version (les autres méthodes utilisent des dates, des horodatages ou des sommes de contrôle/hachages) et vérifient que la version n'a pas changé auparavant. réécrivez l'enregistrement. Lorsque vous réécrivez l'enregistrement, vous filtrez la mise à jour sur la version pour vous assurer qu'elle est atomique. (c’est-à-dire qu’il n’a pas été mis à jour entre le moment où vous vérifiez la version et écrivez l’enregistrement sur le disque) et mettez à jour la version en un seul clic.
Si l’enregistrement est sale (c’est-à-dire une version différente de la vôtre), vous annulez la transaction et l’utilisateur peut le redémarrer.
Cette stratégie est particulièrement applicable aux systèmes à volume élevé et aux architectures à trois niveaux où vous ne maintenez pas nécessairement une connexion à la base de données pour votre session. Dans cette situation, le client ne peut pas réellement conserver les verrous de la base de données car les connexions sont établies à partir d'un pool et il est possible que vous n'utilisiez pas la même connexion d'un accès à l'autre.
Verrouillage pessimiste est le moment où vous verrouillez l'enregistrement pour votre usage exclusif jusqu'à ce que vous en ayez fini. L’intégrité de ce dernier est bien meilleure que celle du verrouillage optimiste, mais vous devez faire attention à la conception de votre application afin d’éviter deadlocks . Pour utiliser le verrouillage pessimiste, vous avez besoin d'une connexion directe à la base de données (comme cela est généralement le cas dans une application serveur client à deux niveaux ) ou d'un ID de transaction disponible en externe pouvant être utilisé indépendamment de la connexion.
Dans ce dernier cas, vous ouvrez la transaction avec le TxID, puis vous vous reconnectez à l'aide de cet ID. Le SGBD maintient les verrous et vous permet de reprendre la session via le TxID. C’est ainsi que fonctionnent les transactions distribuées utilisant des protocoles de validation en deux phases (telles que XA ou COM + Transactions ).
Le verrouillage optimiste est utilisé lorsque vous n'attendez pas beaucoup de collisions. Une opération normale coûte moins cher, mais si la collision se produit, vous devrez payer un prix plus élevé pour la résoudre, car la transaction est annulée.
Le verrouillage pessimiste est utilisé lorsqu'une collision est anticipée. Les transactions qui violeraient la synchronisation sont simplement bloquées.
Pour sélectionner le mécanisme de verrouillage approprié, vous devez estimer le nombre de lectures et de écritures et planifier en conséquence.
Optimiste suppose que rien ne va changer pendant que vous le lisez.
Pessimiste suppose que quelque chose va et donc le verrouille.
S'il n'est pas essentiel que les données soient parfaitement lues, utilisez-les avec optimisme. Vous pouvez peut-être lire quelque chose de "sale" - mais il est beaucoup moins susceptible d'entraîner des blocages, etc.
La plupart des applications Web fonctionnent correctement avec des lectures modifiées - à de rares occasions, les données ne correspondent pas exactement au prochain rechargement.
Pour les opérations de données exactes (comme dans de nombreuses transactions financières), utilisez pessimiste. Il est essentiel que les données soient lues avec précision, sans modifications non affichées - la surcharge de verrouillage supplémentaire en vaut la peine.
Oh, et le serveur Microsoft SQL utilise par défaut le verrouillage de la page - en gros la ligne que vous lisez et quelques-uns des deux côtés. Le verrouillage des lignes est plus précis mais beaucoup plus lent. Il est souvent utile de définir vos transactions en lecture seule ou sans verrouillage pour éviter les blocages lors de la lecture.
Outre ce qui a déjà été dit, il convient de noter que le verrouillage optimiste tend à améliorer la concurrence au détriment de la prévisibilité. Le verrouillage pessimiste tend à réduire la concurrence, mais est plus prévisible.
Vous payez votre argent, etc
Je penserais à un cas de plus où un verrouillage pessimiste serait un meilleur choix.
Pour un verrouillage optimiste, chaque participant à la modification de données doit accepter l'utilisation de ce type de verrouillage. Mais si quelqu'un modifie les données sans se préoccuper de la colonne de version, cela gâchera toute l'idée du verrouillage optimiste.
Il existe essentiellement deux réponses les plus populaires. Le premier dit fondamentalement
Optimistic a besoin d'une architecture à trois niveaux dans laquelle vous ne maintenez pas nécessairement une connexion à la base de données pour votre session, alors que le verrouillage pessimiste consiste à verrouiller l'enregistrement pour votre usage exclusif jusqu'à ce que vous en ayez fini. Son intégrité est bien meilleure que celle du verrouillage optimiste. Vous avez besoin d’une connexion directe à la base de données.
optimistic (versioning) est plus rapide en raison de l'absence de verrouillage, mais le verrouillage (pessimiste) donne de meilleurs résultats lorsque la contention est forte et il est préférable d'éviter le travail plutôt que de le supprimer et de recommencer.
ou
Le verrouillage optimiste fonctionne mieux lorsque vous avez des collisions rares
comme il est mis sur cette page.
J'ai créé ma réponse pour expliquer comment "garder la connexion" est lié à "peu de collisions".
Pour comprendre quelle stratégie est la meilleure pour vous, ne pensez pas au nombre de transactions par seconde de votre base de données, mais à la durée d’une transaction unique. Normalement, vous ouvrez la transaction, effectuez une opération et fermez la transaction. C’est une transaction classique et brève que ANSI avait à l’esprit et qui convenait parfaitement pour échapper au verrouillage. Mais comment implémenter un système de réservation de billets où de nombreux clients réservent les mêmes chambres/sièges en même temps?
Vous parcourez les offres, remplissez le formulaire avec beaucoup d'options disponibles et les prix actuels. Cela prend beaucoup de temps et les options peuvent devenir obsolètes, tous les prix invalides entre vous avez commencé à remplir le formulaire et cliquez sur le bouton "Je suis d'accord" car les données auxquelles vous avez accédé ne sont pas verrouillées et qu'une autre personne, plus agile, s'est interférée. changer tous les prix et vous devez redémarrer avec de nouveaux prix.
Vous pouvez verrouiller toutes les options pendant que vous les lisez. C'est un scénario pessimiste. Vous voyez pourquoi ça craint. Votre système peut être détruit par un seul clown qui commence simplement une réservation et fume. Personne ne peut rien réserver avant d'avoir fini. Votre flux de trésorerie tombe à zéro. C'est pourquoi, les réserves optimistes sont utilisées dans la réalité. Ceux qui traînent trop longtemps doivent recommencer leur réservation à des prix plus élevés.
Dans cette approche optimiste, vous devez enregistrer toutes les données que vous avez lues (comme dans mine répétée lire ) et arriver au point de départ avec votre version des données (je veux acheter des actions au prix que vous avez affiché dans cette citation, pas le prix actuel). À ce stade, la transaction ANSI est créée, ce qui verrouille la base de données, vérifie si rien n'est modifié et valide/annule votre opération. OMI, il s’agit d’une émulation efficace de MVCC , qui est également associée à Optimistic CC et suppose également que votre transaction redémarre en cas d’abandon, c’est-à-dire que vous ferez une nouvelle réservation. Une transaction implique des décisions utilisateur humaines.
Je suis loin de comprendre comment implémenter manuellement MVCC, mais je pense que des transactions de longue durée avec option de redémarrage sont la clé pour comprendre le sujet. Corrigez-moi si je me trompe n'importe où. Ma réponse a été motivée par ce chapitre Alex Kuznecov .
Dans la plupart des cas, le verrouillage optimiste est plus efficace et offre de meilleures performances. Lorsque vous choisissez un verrouillage pessimiste ou optimiste, tenez compte des points suivants:
Le verrouillage pessimiste est utile s’il ya beaucoup de mises à jour et que le risque que les utilisateurs tentent de mettre à jour les données simultanément soit relativement élevé. Par exemple, si chaque opération peut mettre à jour un grand nombre d'enregistrements à la fois (la banque peut ajouter des intérêts créditeurs à chaque compte à la fin de chaque mois) et que deux applications exécutent de telles opérations en même temps, elles auront des conflits. .
Le verrouillage pessimiste est également plus approprié dans les applications contenant de petites tables fréquemment mises à jour. Dans le cas de ces soi-disant points chauds, les conflits sont tellement probables que le verrouillage optimiste gaspille l’effort pour annuler les transactions en conflit.
Le verrouillage optimiste est utile si la possibilité de conflits est très faible - il existe de nombreux enregistrements mais relativement peu d'utilisateurs, ou très peu de mises à jour et principalement des opérations de type lecture.
Un cas d'utilisation pour le verrouillage optimiste consiste à ce que votre application utilise la base de données pour permettre à l'un de vos threads/hôtes de "réclamer" une tâche. C'est une technique qui m'est utile régulièrement.
Le meilleur exemple que je puisse imaginer concerne une file de tâches mise en œuvre à l'aide d'une base de données, avec plusieurs threads réclamant des tâches simultanément. Si une tâche a le statut "Disponible", "Réclamé", "Terminée", une requête de base de données peut indiquer quelque chose du type "Définir le statut =" Réclamé "où statut =" Disponible ". Si plusieurs threads tentent de modifier le statut de cette manière, tous sauf le premier thread échoueront à cause de données altérées.
Notez qu'il s'agit d'un cas d'utilisation impliquant uniquement un verrouillage optimiste. Ainsi, au lieu de dire "Le verrouillage optimiste est utilisé lorsque vous ne vous attendez pas à beaucoup de collisions", vous pouvez également l'utiliser lorsque vous vous attendez à des collisions mais que vous souhaitez exactement une transaction aboutir.