Если выполнять указанный ниже кусок кода в 3х параллельных потоках, то:
1) Один поток захватывает, остальные ждут (ожидаемое поведение)
2) После разблокирования еще один поток захватывает, а вот остальные падают с "Transaction (Process ID 71) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction."

set transaction isolation level serializable

begin tran
update [log].[LockerForChange] set [DateAdd] = sysdatetime();

-- некие еще долгие действия

commit tran


Подскажите пожалуйста, что мне с этим делать?

Здравствуйте, mch-mf.ru, Вы писали:

MMR>Если выполнять указанный ниже кусок кода в 3х параллельных потоках, то:
MMR>1) Один поток захватывает, остальные ждут (ожидаемое поведение)
MMR>2) После разблокирования еще один поток захватывает, а вот остальные падают с "Transaction (Process ID 71) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction."
MMR>set transaction isolation level serializable

MMR>...

Начать с получения Deadlock graph с помощью профайлера, а дальше действовать по результатам

On 04/10/2012 12:40 PM, mch-mf.ru wrote:

> Если выполнять указанный ниже кусок кода в 3х параллельных потоках, то:

Я даже смотреть не буду что оно там делает.

> Подскажите пожалуйста, что мне с этим делать?

С "этим" делать то же, что должно делать любое приложение
для обработки ситуации дедлока, которая вообще-то неизбежна в любой БД.
А именно -- приложение должно
-- откатить текущую транзакцию (в которой возник дедлок), если это СУБД не
делает автоматически.
-- повторить последнюю транзакцию сначала.

> 2) После разблокирования еще один поток захватывает, а вот остальные падают с
> "Transaction (Process ID 71) was deadlocked on lock resources with another
> process and has been chosen as the deadlock victim. Rerun the transaction."

А СУБД какая ?

MMR>update [log].[LockerForChange] set [DateAdd] = sysdatetime();



Это означает, что команда выше ставит несколько блокировок и, при этом, порядок их получения не гарантирован.
Сколько строк в таблице? Есть ли на таблице кластерный индекс? Попробуйте создать, если нет.

Здравствуйте, MasterZiv, Вы писали:

MZ>On 04/10/2012 12:40 PM, mch-mf.ru wrote:

>> Если выполнять указанный ниже кусок кода в 3х параллельных потоках, то:

MZ>Я даже смотреть не буду что оно там делает.

>> Подскажите пожалуйста, что мне с этим делать?

MZ>С "этим" делать то же, что должно делать любое приложение
MZ>для обработки ситуации дедлока, которая вообще-то неизбежна в любой БД.
MZ>А именно -- приложение должно
MZ>-- откатить текущую транзакцию (в которой возник дедлок), если это СУБД не
MZ>делает автоматически.
MZ>-- повторить последнюю транзакцию сначала.



Автор вопроса как раз и пытался избежать такого решения.
Модель с повтором транзакции — это optimistic concurrency, автору же нужно pessimistic — один делает, все остальные ждут в очереди.
И проблема у него в том, что вся очередь в дверь одновременно полезла.

Вот тут, что-то подобное обсуждается.
http://stackoverflow.com/questions/1483725/select-for-update-with-sql-server

> Автор вопроса как раз и пытался избежать такого решения.
> Модель с повтором транзакции — это optimistic concurrency, автору же нужно
> pessimistic — один делает, все остальные ждут в очереди.
> И проблема у него в том, что вся очередь в дверь одновременно полезла.

DEADLOCK-и есть везде и всегда, к ним надо быть всегда готовым.

On 04/10/2012 12:40 PM, mch-mf.ru wrote:

> set transaction isolation level serializable

Мысть 1 -- isolation level serializable тут ни при чём.
Убирай, стало быть.

Мысль 2 -- к дедлоку готовься (на клиенте делается).

Мысль 3 -- нужно гарантировать, что нет эскалации блокировки таблицы.
Где where в UPDATE ?