Grande différence, TABLOCK essaiera de saisir les verrous "partagés", et TABLOCKX verrous exclusifs.
Si vous êtes dans une transaction et que vous saisissez un verrou exclusif sur une table, EX :
SELECT 1 FROM TABLE WITH (TABLOCKX)
Aucun autre processus ne pourra saisir tout verrous sur la table, c'est-à-dire tous les requêtes tentant de parler à la table seront bloquées jusqu'à ce que la transaction soit validée.
TABLOCK ne saisit qu'un verrou partagé, les verrous partagés sont libérés après l'exécution d'une instruction si l'isolement de votre transaction est READ COMMITTED (défaut). Si votre niveau d'isolement est plus élevé, par exemple :SERIALIZABLE , les verrous partagés sont conservés jusqu'à la fin d'une transaction.
Les verrous partagés sont, hmmm, partagés. Cela signifie que 2 transactions peuvent lire les données de la table en même temps si elles détiennent toutes les deux un verrou S ou IS sur la table (via TABLOCK ). Cependant, si transaction A détient un verrou partagé sur une table, transaction B ne pourra pas saisir un verrou exclusif tant que tous les verrous partagés ne seront pas libérés. Découvrez quels verrous sont compatibles avec lesquels sur msdn.
Les deux conseils font que la base de données contourne la prise de verrous plus granulaires (comme les verrous au niveau de la ligne ou de la page). En principe, des verrous plus granulaires vous permettent une meilleure simultanéité. Ainsi, par exemple, une transaction pourrait mettre à jour la ligne 100 de votre table et une autre ligne 1000, en même temps à partir de deux transactions (cela devient délicat avec les verrous de page, mais passons cela).
En général, les verrous granulaires sont ce que vous voulez, mais parfois vous voudrez peut-être réduire la simultanéité de la base de données pour augmenter les performances d'une opération particulière et éliminer les risques de blocages.
En général, vous n'utiliserez pas TABLOCK ou TABLOCKX à moins que vous n'en ayez absolument besoin pour un cas particulier.
