Verrouillage optimiste ou pessimiste

le verrouillage optimiste est utilisé quand vous ne vous attendez pas à beaucoup de collisions. Il en coûte moins pour effectuer une opération normale, mais si la collision se produit, vous paierez un prix plus élevé pour la résoudre à mesure que la transaction est annulée.

verrouillage Pessimiste est utilisé lorsqu'une collision est prévue. Les transactions qui violeraient la synchronisation sont simplement bloquées.

pour sélectionner le mécanisme de verrouillage approprié, vous devez estimer la quantité de lectures et écrit 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 utiliser optimiste. Vous pourriez obtenir le "sale" étrange de lecture - mais il est beaucoup moins probable d'entraîner des blocages et autres.

la plupart des applications web sont très bien avec des lectures sales - dans les rares cas, les données ne sont pas exactement décompte le prochain rechargement.

pour les opérations exactes de données (comme dans de nombreuses transactions financières) utiliser pessimiste. Il est essentiel que les données soient lues avec précision, sans aucune modification non montrée-le verrouillage supplémentaire de la tête en vaut la peine.

Oh, et Microsoft SQL server par défaut à la page locking-essentiellement la ligne que vous lisez et quelques uns de chaque côté. Le verrouillage des rangées est plus précis, mais beaucoup plus lent. Il est souvent utile de définir vos transactions à lire-engagé ou pas de serrure pour éviter les blocages pendant la lecture.

en plus de ce qui a déjà été dit, il faut dire 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 il est plus prévisible.

vous payez votre argent, etc

je pense à un cas de plus où un verrouillage pessimiste serait un meilleur choix.

pour un verrouillage optimiste, chaque participant à la modification des données doit accepter d'utiliser ce type de verrouillage. Mais si quelqu'un modifie les données sans s'occuper de la colonne version, cela gâchera toute l'idée du verrouillage optimiste.

il y a essentiellement deux réponses les plus populaires. Le premier dit en gros

Optimist a besoin d'une architecture à trois niveaux où vous ne maintenez pas nécessairement une connexion à la base de données pour votre session, tandis que le verrouillage pessimiste est lorsque vous verrouillez l'enregistrement pour votre usage exclusif jusqu'à ce que vous avez terminé avec elle. Il a une meilleure intégrité que le verrouillage optimiste, vous avez besoin soit d'une connexion directe à la la base de données.

une autre réponse est

optimiste (versioning) est plus rapide en raison de l'absence de blocage, mais (pessimiste) de verrouillage fonctionne mieux lorsque le conflit est élevé et il est préférable de s'opposer à la tâche plutôt que de jeter et recommencer.

ou

le verrouillage optimiste fonctionne mieux lorsque vous avez de rares collisions

comme il est mis sur cette page.

j'ai créé ma réponse pour expliquer comment" keep connection "est lié à"Low collisions".

pour comprendre quelle stratégie est la meilleure pour vous, ne pensez pas aux Transactions par seconde votre PB A mais la durée d'une seule transaction. Normalement, vous ouvrez trasnaction, effectuez une opération et fermez la transaction. Il s'agit d'une transaction courte, classique ANSI avait en esprit et amende de s'en sortir avec la fermeture. Mais, comment mettre en place 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 naviguez sur l'offre, 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 ont commencé à remplir le formulaire et appuyez sur" j'accepte " bouton parce qu'il n'y avait pas de verrouillage sur les données que vous avez accédé et quelqu'un d'autre, plus agile, a intégré changer tous les prix et vous devez redémarrer avec de nouveaux prix.

vous pouvez verrouiller toutes les options pendant que vous les lisez, à 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 rien réserver avant qu'il ait 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 redémarrez leur réservation à des prix plus élevés.

dans cette approche optimiste, vous devez enregistrer toutes les données que vous lisez (comme dans le mien répété Lire ) et venir au point d'engagement avec votre version de données (je veux acheter des actions au prix que vous avez affiché dans cette soumission, pas le prix actuel). À ce point, une transaction ANSI est créée, qui bloque la base de données, vérifie si rien n'est changé et commet/annule votre opération. IMO, c'est efficace l'émulation de MVCC , qui est également associée à CC optimiste et suppose également que votre transaction redémarre en cas d'abandon, c'est-à-dire que vous ferez une nouvelle réservation. Une transaction ici implique une décision d'utilisateur humain.

je suis loin de comprendre comment mettre en œuvre manuellement le MVCC, mais je pense que les transactions à long terme avec option de redémarrage est la clé pour comprendre le sujet. Corrigez-moi si je me trompe, n'importe où. Ma réponse a été motivé par ce chapitre D'Alex Kuznecov .

dans la plupart des cas, le verrouillage optimiste est plus efficace et offre des performances supérieures. Lorsque vous choisissez entre un verrouillage pessimiste et optimiste, tenez compte de ce qui suit:

• le verrouillage pessimiste est utile s'il y a beaucoup de mises à jour et les chances relativement élevées d'utilisateurs essayant de mettre à jour les données à la même temps. Par exemple, si chaque opération peut mettre à jour un grand nombre de enregistrements à la fois (la banque pourrait ajouter les revenus d'intérêts, de chacun compte à la fin de chaque mois), et deux applications sont en cours d'exécution de telles opérations en même temps, ils auront des conflits.

• le verrouillage pessimiste est également plus approprié dans les applications qui contiennent de petites tables qui sont fréquemment mises à jour. Dans le cas de ces "points chauds", les conflits sont si probables qu'un verrouillage optimiste gaspille l'effort pour faire reculer les transactions conflictuelles.

• 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 surtout des opérations de lecture.

un des cas d'utilisation pour un verrouillage optimiste est de faire en sorte que votre application utilise la base de données pour permettre à l'un de vos threads / hosts de "revendiquer" une tâche. C'est une technique qui a venir dans maniable pour moi sur une base régulière.

le meilleur exemple que je puisse imaginer est pour une file d'attente de tâche implémentée en utilisant 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é', 'complété', une requête de base de données peut dire quelque chose comme "Set status= 'Claimed' où status='Disponible'. Si plusieurs threads essayent de changer le statut de cette façon, tous les threads, sauf le premier, échoueront à cause des données sales.

noter qu'il s'agit d'un cas d'utilisation ne comportant qu'un verrouillage optimiste. Ainsi, au lieu de dire "verrouillage optimiste est utilisé lorsque vous ne vous attendez pas à beaucoup de collisions", il peut également être utilisé lorsque vous vous attendez à des collisions, mais que vous voulez exactement une transaction pour réussir.