Stor forskel, TABLOCK vil prøve at få fat i "delte" låse og TABLOCKX eksklusive låse.
Hvis du er i en transaktion, og du snupper en eksklusiv lås på et bord, f.eks.:
SELECT 1 FROM TABLE WITH (TABLOCKX)
Ingen andre processer vil være i stand til at fange nogen låse på bordet, hvilket betyder alle forespørgsler, der forsøger at tale til bordet, vil blive blokeret, indtil transaktionen forpligtes.
TABLOCK griber kun en delt lås, delte låse frigives efter en erklæring er udført, hvis din transaktionsisolering er READ COMMITTED (Standard). Hvis dit isolationsniveau er højere, for eksempel:SERIALIZABLE , delte låse holdes indtil slutningen af en transaktion.
Delte låse er, hmmm, delte. Det betyder, at 2 transaktioner begge kan læse data fra tabellen på samme tid, hvis de begge har en S- eller IS-lås på bordet (via TABLOCK ). Men hvis transaction A har en delt lås på et bord, transaction B vil ikke være i stand til at få fat i en eksklusiv lås, før alle delte låse er frigivet. Læs om hvilke låse der er kompatible med hvilke på msdn.
Begge tip får db til at omgå at tage mere granulære låse (som række- eller sideniveaulåse). I princippet giver mere granulerede låse dig bedre samtidighed. Så for eksempel kan én transaktion være at opdatere række 100 i din tabel og en anden række 1000, på samme tid fra to transaktioner (det bliver vanskeligt med sidelåse, men lad os springe det over).
Generelt er granulære låse, hvad du ønsker, men nogle gange vil du måske reducere db samtidighed for at øge ydeevnen af en bestemt operation og eliminere chancen for deadlocks.
Generelt ville du ikke bruge TABLOCK eller TABLOCKX medmindre du absolut havde brug for det til en kantkasse.