Je comprends les différences entre un verrouillage optimiste et pessimiste. Maintenant, quelqu'un pourrait-il m'expliquer quand je devrais utiliser 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 exécuter la requête ?
Mais juste pour vérifier, optimiste signifie "ne pas verrouiller la table pendant la lecture" et pessimiste signifie "verrouiller la table pendant la lecture".
Verrouillage optimiste est une stratégie qui consiste à lire un enregistrement, à prendre note d'un numéro de version (d'autres méthodes pour ce faire font appel à des dates, des horodatages ou des checksums/hashes) et à vérifier que la version n'a pas changé avant de réécrire 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'elle n'a pas été mise à jour entre le moment où vous vérifiez la version et celui où vous écrivez l'enregistrement sur le disque) et mettez à jour la version en une seule fois.
Si l'enregistrement est sale (c'est-à-dire une version différente de la vôtre), vous interrompez la transaction et l'utilisateur peut la relancer.
Cette stratégie s'applique surtout aux systèmes à haut volume 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 maintenir les verrous de la base de données, car les connexions sont prises dans un pool et il se peut que vous n'utilisiez pas la même connexion d'un accès à l'autre.
Verrouillage pessimiste consiste à verrouiller l'enregistrement pour votre usage exclusif jusqu'à ce que vous ayez fini de l'utiliser. L'intégrité est bien meilleure que celle du verrouillage optimiste, mais vous devez faire attention à la conception de votre application pour éviter Impasses . Pour utiliser le verrouillage pessimiste, vous avez besoin soit d'une connexion directe à la base de données (comme c'est généralement le cas dans une application de type client serveur à deux niveaux ) ou un ID de transaction disponible en externe qui peut être utilisé indépendamment de la connexion.
Dans ce dernier cas, vous ouvrez la transaction avec le TxID et vous vous reconnectez ensuite en utilisant cet ID. Le SGBD maintient les verrous et vous permet de reprendre la session par l'intermédiaire du TxID. C'est ainsi que les transactions distribuées utilisant des protocoles de validation en deux phases (tels que XA ou Transactions COM+ ) travaillent.
Le verrouillage optimiste n'utilise pas nécessairement un numéro de version. D'autres stratégies consistent à utiliser (a) un horodatage ou (b) l'état complet de la ligne elle-même. Cette dernière stratégie est laide mais évite d'avoir à utiliser une colonne de version dédiée, dans les cas où vous ne pouvez pas modifier le schéma.
Le concept de verrouillage optimiste ne nécessite pas nécessairement de disposer d'un moyen fiable à 100 % pour savoir si quelque chose a été modifié ou non ; des modifications indétectables ne sont pas acceptables, mais de faux rapports occasionnels d'altération peuvent ne pas être trop graves, surtout si le code qui reçoit un tel rapport relit les données et vérifie si elles ont réellement été modifiées.
@ConcernedOfTunbridgeWells J'ai une question complémentaire sur le troisième paragraphe de votre réponse. Vous avez écrit "Dans cette situation, le client ne peut pas réellement maintenir les verrous de base de données car les connexions sont prises dans un pool et vous pouvez ne pas utiliser la même connexion d'un accès à l'autre.". Pourquoi dois-je avoir la même connexion entre deux appels différents pour pouvoir utiliser des verrous de base de données ?
Le verrouillage optimiste est utilisé lorsque vous ne prévoyez pas de nombreuses collisions. Il est moins coûteux d'effectuer une opération normale, mais si une collision se produit, vous devrez payer un prix plus élevé pour la résoudre, car la transaction sera interrompue.
Le verrouillage pessimiste est utilisé lorsqu'une collision est prévue. Les transactions qui violeraient la synchronisation sont simplement bloquées.
Pour choisir le mécanisme de verrouillage approprié, vous devez estimer le nombre de lectures et d'écritures et planifier en conséquence.
L'optimisme suppose que rien ne va changer pendant que vous le lisez.
Le pessimiste suppose que quelque chose arrivera et le verrouille.
S'il n'est pas essentiel que les données soient parfaitement lues, utilisez la méthode optimiste. Il se peut que vous soyez confronté à une lecture "sale", mais il est beaucoup moins probable que cela entraîne des blocages et autres problèmes.
La plupart des applications web ne posent pas de problème en cas de lecture incorrecte - les rares fois où les données ne correspondent pas exactement, le prochain rechargement le fait.
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 page - essentiellement la ligne que vous lisez et quelques autres de chaque côté. Le verrouillage des rangées est plus précis mais beaucoup plus lent. Il est souvent utile de configurer vos transactions en read-committed ou no-lock pour éviter les blocages pendant la lecture.
La cohérence de la lecture est une préoccupation distincte. Avec PostgreSQL, Oracle et de nombreuses autres bases de données, vous obtenez une vue cohérente des données indépendamment des mises à jour non encore validées, et vous n'êtes pas affecté même par les verrous exclusifs de rangée.
Je suis d'accord avec @RichVel. D'une part, je peux voir comment le verrouillage pessimiste pourrait empêcher les lectures sales si votre niveau d'isolation de transaction est READ UNCOMMITTED. Mais il est trompeur de dire que le verrouillage optimiste est susceptible de provoquer des lectures malencontreuses sans mentionner que la plupart des bases de données (y compris apparemment MS SQL Server) ont un niveau d'isolation par défaut de "READ COMMITTED", qui empêche les lectures malencontreuses et rend le verrouillage optimiste tout aussi précis que le pessimiste.
Je pense à un autre cas où un verrouillage pessimiste serait un meilleur choix.
Pour le verrouillage optimiste, chaque participant à la modification des données doit être d'accord pour utiliser ce type de verrouillage. Mais si quelqu'un modifie les données sans se soucier de la colonne version, cela gâchera toute l'idée du verrouillage optimiste.
Les personnes qui tentent d'utiliser le verrouillage optimiste et pessimiste peuvent aussi se marcher sur les pieds, pour ainsi dire. Imaginez un scénario dans lequel une session optimiste lit un enregistrement et effectue des calculs pendant qu'une session pessimiste met à jour l'enregistrement, puis la session optimiste revient et met à jour ce même enregistrement sans noter les modifications apportées. La fonction Select ... for update ne fonctionne que si chaque session utilise la même syntaxe.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
3 votes
blog.couchbase.com/
3 votes
C'est une bonne question, notamment parce que dans sérialisation Je lis
At any technique type conflicts should be detected and considered, with similar overhead for both materialized and non-materialized conflicts.4 votes
Vous trouverez une bonne explication, ici sur SO, sur ce qu'est la Concept de base du verrouillage optimiste .
2 votes
Je vous recommande de lire l'excellent livre de Martin Fowler sur les modèles : martinfowler.com/books/eaa.html
0 votes
Je pense que le contrôle de la concurrence est plus précis que le verrouillage.