Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Verrouillage optimiste vs pessimiste

Le verrouillage optimiste est une stratégie dans laquelle vous lisez un enregistrement, notez un numéro de version (d'autres méthodes pour ce faire impliquent des dates, des horodatages ou des sommes de contrôle/hachages) 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'est-à-dire qu'il n'a pas été mis à 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 un 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 la redémarrer.

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 proviennent 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 terminé. Il a une bien meilleure intégrité que le verrouillage optimiste mais vous oblige à faire attention à la conception de votre application pour éviter les blocages. Pour utiliser le verrouillage pessimiste, vous avez besoin soit d'une connexion directe à la base de données (comme ce serait généralement le cas dans une application client-serveur à deux niveaux), soit 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 en utilisant 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 (tels que les transactions XA ou COM+).