Question en double de:
/programming/129329/optimistic-vs-pessimistic-locking
Copiez / collez la réponse à partir du lien ci-dessus:
Le verrouillage optimiste est une stratégie dans laquelle vous lisez un enregistrement, notez un numéro de version et vérifiez 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.-à-d. n'a pas été mis à jour entre le moment où vous vérifiez la version et l'écriture de 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 abandonnez la transaction et l'utilisateur peut la redémarrer.
Cette stratégie est plus 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 maintenir les verrous de base de données car les connexions sont prises à partir d'un pool et vous n'utilisez peut-être pas la même connexion d'un accès à l'autre.
Le verrouillage pessimiste consiste à verrouiller l'enregistrement pour votre usage exclusif jusqu'à ce que vous en ayez fini avec lui. Il a une bien meilleure intégrité qu'un verrouillage optimiste mais vous oblige à être prudent avec la conception de votre application pour éviter les blocages. Pour utiliser le verrouillage pessimiste, vous avez besoin d'une connexion directe à la base de données (comme ce serait généralement le cas dans une application serveur client à deux niveaux) ou d'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, puis vous reconnectez à l'aide de cet ID. Le SGBD maintient les verrous et vous permet de récupérer la session via le TxID. C'est ainsi que fonctionnent les transactions distribuées utilisant des protocoles de validation en deux phases (telles que les transactions XA ou COM +).
Modifier (en ajoutant plus d'informations pour répondre à la question des performances):
En termes de performances, cela dépend de votre environnement. Prenez en compte les facteurs suivants pour décider:
vous trouverez optimiste sera meilleur en raison de la simultanéité dans la plupart des situations. Selon le SGBDR et l'environnement, cela peut cependant être moins ou plus performant. En règle générale, avec le verrouillage optimiste, vous constaterez que la valeur doit être versionnée en ligne quelque part.
Avec MS SQL Server par exemple, il est déplacé vers TempDB et quelque chose entre 12-14 octets est ajouté à la fin de la colonne. L'activation du verrouillage optimiste avec un niveau d'isolement tel que l'isolement de capture instantanée peut provoquer une fragmentation et votre facteur de remplissage devra être ajusté car les lignes contiennent maintenant des données supplémentaires à la fin, ce qui pourrait entraîner une page presque pleine à provoquer un fractionnement de page, ce qui réduira vos performances. Si votre TempDB est sous-optimisé, ce ne sera pas aussi rapide.
Je suppose donc qu'une liste de contrôle est:
- -Avez-vous suffisamment d'E / S / ressources pour gérer la forme de versionnage des lignes? Sinon, vous ajoutez des frais généraux. Si c'est le cas, alors si vous lisez souvent les données pendant que vous les verrouillez souvent pour les écritures, vous remarquerez une bonne amélioration de la concurrence entre les lectures et les écritures (bien que les écritures bloquent toujours les écritures, les lectures ne bloquent plus les écritures et vice versa)
- -Votre code est-il sensible aux blocages ou rencontrez-vous un verrouillage? Si vous ne rencontrez pas de longs verrous ou de nombreux blocages, le surcoût supplémentaire du verrouillage optimiste ne rendrait pas les choses plus rapides, bien sûr, dans la plupart des cas, nous parlons de millisecondes ici.
- -Si votre base de données est volumineuse (ou sur un matériel très limité) et que vos pages de données sont presque pleines, selon le SGBDR, vous pouvez provoquer des fractionnements de page importants et une fragmentation des données, alors assurez-vous de considérer la réindexation après l'avoir allumée.
Telles sont mes réflexions sur la question, ouvertes à entendre plus de la communauté.