Optimistic vs Pessimistic de verrouillage
Je comprends les différences entre le verrouillage optimiste et pessimiste. Maintenant, quelqu'un pourrait-il m'expliquer quand je voudrais utiliser soit l'un, en général?
Et la réponse à cette question changer en fonction de si oui ou non je suis à l'aide d'une procédure stockée à exécuter la requête?
Mais juste pour vérifier, optimiste signifie "ne pas verrouiller la table lors de la lecture de" et pessimiste signifie "verrouiller la table lors de la lecture."
- blog.couchbase.com/...
- C'est une bonne question d'autant qu'en serializability j'ai lu
At any technique type conflicts should be detected and considered, with similar overhead for both materialized and non-materialized conflicts.
Vous devez vous connecter pour publier un commentaire.
Le Verrouillage Optimiste est une stratégie où vous lisez un enregistrement, prendre note du numéro de version (d'autres méthodes pour ce faire impliquer les dates, les horodateurs ou des sommes de contrôle/de hachages) et de vérifier que la version n'a pas changé avant de vous écrire l'enregistrement. Lorsque vous écrire l'enregistrement, vous filtrez la mise à jour de la version pour s'assurer qu'il est atomique. (c'est à dire n'a pas été mis à jour entre le moment où vous vérifiez la version et écrire l'enregistrement sur le disque) et de mettre à jour la version d'un seul coup.
Si le document est sale (c'est à dire une version différente de la vôtre) vous annuler la transaction et l'utilisateur peut la relancer.
Cette stratégie est la plus applicables à haut volume, et de systèmes à trois niveaux architectures où vous n'avez pas nécessairement à maintenir une connexion à la base de données pour votre session. Dans ce cas, le client ne peut pas fait de maintenir la base de données de serrures comme les connexions sont prises à partir d'un pool et vous ne pouvez pas être en utilisant la même connexion à partir de l'une à l'autre.
Le Verrouillage Pessimiste est lorsque vous verrouillez l'enregistrement pour votre usage exclusif jusqu'à ce que vous avez terminé avec elle. Il a beaucoup mieux à l'intégrité de verrouillage optimiste, mais vous oblige à être prudent avec la conception de votre application afin d'éviter Les blocages. Pour utiliser le verrouillage pessimiste, vous devez disposer d'une connexion directe à la base de données (comme cela pouvait être le cas dans un deux niveaux client serveur application) ou externe disponible ID de transaction qui peut être utilisé indépendamment de la connexion.
Dans le dernier cas, vous ouvrez la transaction avec le TxID et rebranchez-le à l'aide de l'IDENTIFIANT. Le SGBD gère les serrures et vous permet de choisir la session par le TxID. C'est la façon dont les transactions distribuées à l'aide de deux phases de validation des protocoles (tels que XA ou Les Transactions COM+ ) de travail.
Verrouillage optimiste est utilisé lorsque vous ne vous attendez pas beaucoup de collisions. Il en coûte moins pour un fonctionnement normal, mais si la collision NE se produisent que vous auriez à payer un prix plus élevé pour le résoudre et que la transaction est annulée.
Le verrouillage pessimiste est utilisé lorsqu'une collision est prévue. Les transactions qui serait en violation de la synchronisation sont tout simplement bloqués.
Pour sélectionner le bon mécanisme de verrouillage, vous devez estimer le montant de lectures et d'écritures et de planifier en conséquence.
Optimiste suppose que rien ne va changer pendant que vous êtes en train de lire ça.
Pessimiste suppose que quelque chose et donc qu'il se bloque.
Si il n'est pas essentiel que les données sont parfaitement lecture optimiste. Vous pouvez obtenir de l'étrange "sale" lire - mais c'est beaucoup moins susceptible d'entraîner des blocages et la comme.
La plupart des applications web sont très bien avec sale lit - dans les rares cas les données ne sont pas exactement de pointage de la prochaine recharger n'.
Pour connaître les données exactes de l'exploitation (comme dans beaucoup d'opérations financières) utilisation pessimiste. Il est essentiel que les données sont lues de manière précise, sans l'onu montré des changements - le supplément de verrouillage en vaut la peine.
Oh, et Microsoft SQL server par défaut à la page de verrouillage - fondamentalement, la ligne que vous êtes en train de lire et un peu de chaque côté. Le verrouillage de ligne est plus précis, mais beaucoup plus lentement. Il est souvent utile de définir vos transactions de lecture commis ou sans verrou pour éviter les blocages lors de la lecture.
En plus de ce qui a été dit déjà, il faut dire que le verrouillage optimiste a tendance à améliorer la concurrence au détriment de la prévisibilité. Le verrouillage pessimiste tend à réduire la concurrence, mais est de plus en plus prévisible.
Vous paie votre argent, etc
Je pense que de un plus le cas lorsque le verrouillage pessimiste serait un meilleur choix.
Pour le verrouillage optimiste chaque participant à la modification de données doivent être d'accord pour l'utilisation de ce type de verrouillage. Mais si quelqu'un modifie les données sans se soucier de la version colonne, il va gâcher l'ensemble de l'idée de verrouillage optimiste.
Il y a fondamentalement deux des plus populaires de réponses. Le premier dit en gros
Une autre réponse est
ou
Comme il est mis sur cette page.
J'ai créé ma réponse à expliquer comment "maintenir la connexion" est lié à "faible collisions".
De comprendre quelle stratégie est la meilleure pour vous, ne le pense pas sur les Transactions Par Seconde de votre DB, mais la durée d'une seule transaction. Normalement, vous ouvrez trasnaction, performa fonctionnement et la clôture de la transaction. C'est un court classique de transaction ANSI avait dans l'esprit et l'amende à sortir avec verrouillage. Mais, comment mettre en place un système de réservation de ticket où de nombreux clients de la réserve de la même chambres/sièges en même temps?
Vous parcourez l'offre, remplissez le formulaire avec beaucoup d'options disponibles et les prix actuels. Il prend beaucoup de temps et d'options peuvent devenir obsolètes, tous les prix des invalides entre vous ont commencé à remplir le formulaire et appuyez sur bouton "j'accepte" parce qu'il n'y avait pas de verrou sur les données que vous avez consultées et quelqu'un d'autre, plus agile, intefered de changer tous les prix et vous avez besoin de redémarrer avec le nouveau prix.
Vous pouvez verrouiller toutes les options que vous les lire, à la place. C'est le scénario pessimiste. Vous voyez pourquoi elle le suce. Votre système peut être porté par un seul clown qui commence simplement une réservation et va fumer. Personne ne peut réserver quelque chose avant qu'il se termine. Votre flux de trésorerie tombe à zéro. C'est pourquoi, optimiste réservations sont utilisés dans la réalité. Ceux qui stationnent trop longtemps pour redémarrer leur réservation à la hausse des prix.
Dans cette approche optimiste, vous devez enregistrer toutes les données que vous avez lu (comme dans mine de Lecture Répétée) et viennent sur le point de validation avec votre version de données (je veux acheter des actions au prix affiché dans cette citation, pas de prix actuel). À ce stade, ANSI transaction est créée, ce qui verrouille la DB, vérifie si rien n'est changé et s'engage/abandons de votre opération. IMO, c'est efficace émulation de MVCC, qui est également associé avec Optimiste CC et suppose également que votre transaction redémarre en cas d'abandon, qui vous permettra de faire une nouvelle réservation. Une transaction suppose un utilisateur humain décisions.
Je suis loin de comprendre comment mettre en œuvre la MVCC à la main, mais je pense que des transactions de longue durée avec option de redémarrage est la clé de la compréhension de l'objet. Corrigez-moi si je me trompe, n'importe où. Ma réponse a été motivée par cette Alex Kuznecov chapitre.
Dans la plupart des cas, le verrouillage optimiste est plus efficace et offre des performances plus élevées. Au moment de choisir entre optimistes et pessimistes de verrouillage, considérez les points suivants:
Le verrouillage pessimiste est utile si il y a beaucoup de mises à jour et
relativement fortes chances d'utilisateurs en essayant de mettre à jour les données dans le même
temps. Par exemple, si chaque opération peut mettre à jour un grand nombre de
enregistrements à la fois (la banque peut ajouter de l'intérêt bénéfice de tous
compte à la fin de chaque mois), et deux applications sont en cours d'exécution
de telles opérations dans le même temps, ils ont des conflits.
Le verrouillage pessimiste est également plus approprié dans les applications qui contiennent de petites tables qui sont fréquemment mis à jour. Dans le cas de ces hotspots, les conflits sont donc probable que le verrouillage optimiste déchets de l'effort de restauration de conflit transactions.
Verrouillage optimiste est utile si la possibilité de conflits est très
faible – il y a beaucoup de dossiers, mais relativement peu d'utilisateurs, ou très peu de mises à jour et surtout de lire des opérations de type.
Un cas d'utilisation pour le verrouillage optimiste est d'avoir votre utilisation de l'application de la base de données pour permettre à l'un de vos threads /hosts pour "demande" une tâche. C'est une technique qui a venir dans maniable pour moi sur une base régulière.
Le meilleur exemple est, je pense, pour une tâche de la file d'attente mis en œuvre à l'aide d'une base de données, avec plusieurs threads prétendant tâches simultanément. Si une tâche a le statut "Disponible", "a fait valoir', 'Terminée', db requête peut dire quelque chose comme "Set status='Réclamée' where statut='Disponible'. Si plusieurs threads tentent de changer le statut de cette façon, tous, mais le premier thread va échouer à cause de la saleté de données.
Noter que c'est un cas d'utilisation n'impliquant que le verrouillage optimiste. Donc, comme une alternative de dire "Optimiste verrouillage est utilisé lorsque vous ne vous attendez pas beaucoup de collisions", il peut également être utilisé lorsque vous vous attendez à des collisions mais voulez exactement une seule transaction pour réussir.
Beaucoup de bonnes choses ont été dites ci-dessus à propos de verrouillage optimiste et pessimiste.
Un point important à considérer est comme suit:
Lorsque vous utilisez le verrouillage optimiste, nous devons prudents sur le fait que la candidature de récupérer de ces échecs.
Spécialement dans asynchrone par message architectures, cela peut engendrer de sortir de l'ordre de traitement des messages ou des mises à jour perdues.
Échecs scénarios doivent être pensée à travers.
Lorsque vous traitez avec des conflits, vous avez deux options:
Maintenant, considérons la suite Perdu anomalie de mise à Jour:
La Perdu de mise à Jour de l'anomalie peut se produire dans le Read Committed niveau d'isolation.
Dans le diagramme ci-dessus, nous pouvons voir qu'Alice croit qu'elle peut retirer de 40 à partir de son
accountmais ne se rend pas compte que Bob a juste changé le solde du compte, et maintenant il ya seulement 20 à gauche dans ce compte.Le Verrouillage Pessimiste
Le verrouillage pessimiste atteint cet objectif en prenant une commune ou verrou de lecture sur le compte afin de Bob est empêché de modifier le compte.
Dans le diagramme ci-dessus, les deux Alice et Bob vont acquérir un verrou en lecture sur le
accountligne de la table, que les deux utilisateurs ont lu. La base de données acquiert ces verrous sur SQL Server lors de l'utilisation de Repeatable Read ou Serializable.Parce que les deux Alice et Bob ont lu le
accountavec la valeur de clé primaire de1, aucun des deux ne peut le modifier jusqu'à ce qu'un utilisateur relâche le verrou en lecture. C'est parce que d'une opération d'écriture nécessite une écriture/verrouillage exclusif l'acquisition, et partagé/lire les verrous empêchent d'écrire/verrous exclusifs.Seulement après Alice a commis son opération et le verrou en lecture a été publié sur le
accountligne, BobUPDATEva reprendre et appliquer la modification. Jusqu'à ce qu'Alice libère le verrou en lecture, Bob blocs de mise à JOUR.Verrouillage Optimiste
Verrouillage optimiste permet le conflit à se produire, mais qu'il détecte lors de l'application d'Alice est mise à JOUR que la version a changé.
Cette fois, nous avons un montant supplémentaire
versioncolonne. Leversioncolonne est incrémenté à chaque fois qu'une mise à JOUR ou à SUPPRIMER est exécutée, et elle est également utilisée dans la clause where de l'UPDATE et DELETE. Pour que cela fonctionne, nous avons besoin de question de le SÉLECTIONNER et de lire le courantversionavant l'exécution de la mise à JOUR ou de les SUPPRIMER, car, sinon, nous ne savons pas quelle est la version de la valeur à passer à la clause where ou pour incrémenter.Au niveau de l'Application des opérations
De bases de données relationnelles les systèmes ont émergé à la fin des années 70 début des années 80 quand un client, généralement, se connecter à un ordinateur central par l'intermédiaire d'un terminal. C'est pourquoi nous voyons toujours des systèmes de base de données définir des termes comme paramètre de SESSION.
Aujourd'hui, sur Internet, on n'exécute plus les lectures et écritures dans le cadre de la même transaction de base de données, et de l'ACIDE n'est plus suffisante.
Par exemple, considérons la suite de cas d'utilisation:
Sans verrouillage optimiste, il n'est en aucune façon Perdu de mise à Jour aurait été pris, même si les transactions de base de données utilisé Serializable. C'est parce que les lectures et les écritures sont exécutées en séparer les requêtes HTTP, et donc sur les différentes transactions de base de données.
Donc, verrouillage optimiste peut vous aider à éviter la perte de Mises à jour, même lors de l'utilisation de transactions au niveau des applications qui intègrent l'utilisateur pense que le temps ainsi.
Conclusion
Verrouillage optimiste est une technique très utile, et il fonctionne très bien, même lors de l'utilisation de moins stricte des niveaux d'isolement, comme Lire Commis, ou lorsque les lectures et les écritures sont exécutées dans la suite des transactions de base de données.
L'inconvénient de verrouillage optimiste est qu'un rollback sera déclenché par l'accès aux données-cadre lors de la capture d'un
OptimisticLockException, par conséquent, de perdre tout le travail que nous avons fait précédemment en cours d'exécution de la transaction.Le plus conflictuel, plus de conflits, et plus grande est la chance de l'abandon de transactions. Les restaurations peuvent être coûteux pour le système de base de données comme il se doit de revenir toutes les modifications en attente qui peut impliquer à la fois les lignes de la table et d'index des enregistrements.
Pour cette raison, le verrouillage pessimiste peut-être minerai adapté lorsque des conflits se produisent fréquemment, car il réduit le risque de l'annulation de transactions.