Много читал о взаимоблокировках, и когда я подумал, что хорошо это знаю, возникает проблема.
В одно и то же время происходят две похожие транзакции.Они выглядят следующим образом:
BEGIN TRAN //read_committed_snapshot ON
//an application sends insert query
INSERT INTO t1 VALUES('Name',15)
//later on application sends update query for the newly inserted row
UPDATE t1 SET name='NewName', number=16 WHERE id = 10 //this ID is the id of the inserted row.
COMMIT
Данный код не является тем, который я использую в своем приложении, но идея та же, у него просто больше столбцов.
Таблица t1 имеетидентификатор первичного ключа, некоторые некластеризованные индексы.
После одновременного выполнения двух транзакций он блокируется.Профилировщик говорит, что для каждого из конфликтующих процессов это был заблокированный запрос UPDATE t1 SET name='NewName', number=16 WHERE id = :id.
Извините, у меня нет XML тупика, но профилировщик сказал, что оба процесса имели X-блокировку и оба пыталисьдля получения U-блокировок.
process 1
owner - X
waiter - U
process 2
owner - X
waiter - U
t1 таблица была показана для обоих процессов как объект, а индекс PK_id как indexname.
Так что же на самом деле здесь происходит?Каждая транзакция обновляет разные строки в одной и той же таблице, почему она зашла в тупик?
Многие примеры в сети говорят: «Эй, это из-за того, как она сканирует индексы, сканирует индекс pk для одной транзакции и некоторый другой некластеризованный индекс для другой».транзакции », но их графики взаимоблокировок профилировщика показывают разные значения в indexname, так что это не то же самое, что у меня, имя индекса такое же.
Есть идеи, как решить эту проблему?Это сводит меня с ума.Я думал, что включение read_committed_snapshot решит эту проблему, но я ошибся.