Wyłączność X zamki a U zamki
W poniższej macierzy kompatybilności zamka widać, że X blokada jest zgodna tylko ze stabilnością schematu i typami blokady Wstaw zakres-Null. U jest kompatybilny z następującymi dodatkowymi współdzielonymi typami blokad S /IS /RS-S /RI-S /RX-S
macierz kompatybilności blokady http://i.msdn.microsoft.com/ms186396.LockConflictTable(en-us,SQL.105).gif
Dokładność X zamki
Są one dobrze usuwane na wszystkich poziomach. Poniższy ślad skryptu i profilera pokazuje, że zostały pomyślnie usunięte na poziomie wiersza.
CREATE TABLE test_table (id int identity(1,1) primary key, col char(40))
INSERT INTO test_table
SELECT NEWID() FROM sys.objects
select * from test_table with (rowlock,XLOCK) where id=10
Ale wiersze nadal można odczytać!
Okazuje się, że przy read committed poziom izolacji SQL Server nie zawsze usuwa S blokady, pominie ten krok, jeśli nie ma ryzyka odczytania niezatwierdzonych danych bez nich. Oznacza to, że nie ma gwarancji, że kiedykolwiek wystąpi konflikt blokady.
Jeśli jednak początkowy wybór to with (paglock,XLOCK) to będzie zatrzymaj transakcję odczytu jako X blokada strony zablokuje IS blokada strony, która zawsze będzie potrzebna czytelnikowi. Będzie to oczywiście miało wpływ na współbieżność.
Inne zastrzeżenia
Nawet jeśli zablokujesz wiersz/stronę, nie oznacza to, że blokujesz wszystkie dostępy do tego wiersza w tabeli. Blokada wiersza w indeksie klastrowym nie zapobiegnie odczytywaniu przez zapytania danych z odpowiedniego wiersza w pokrywającym indeksie nieklastrowym.
