Пытался смоделировать дедлок в 1С в разных режимах и разными способами, максимум что удалось сделать - отловить в ЦУПЕ и профайлере таймауты. Почитал на сайте MSDN - оказалось в 2008 сервере понятие дедлока есть только в теории, на практике монитор блокировок при обнаружении конфликта, выбирает "жертву" взаимоблокировки и откатывает эту транзакцию, вторая транзакция завершается нормально.
Получается что дедлоки - это невоспроизводимая ситуация или я не так что-то понял? Зачем тогда в профайлере и ЦУПЕ различные инструменты по обнаружению и анализу взаимоблокировок остались?

Наверное потому что в8 работает не только с МС СКЛ?

хм... да, не так сформулировал вопрос. Про 2008 SQL я правильно понял?

нет, не правильно. взаимоблокировка никуда не девается, а разруливать их любой sql server умеет

"на практике монитор блокировок при обнаружении конфликта, выбирает "жертву" взаимоблокировки и откатывает эту транзакцию, вторая транзакция завершается нормально" - такое поведение имхо еще с 2000го сервера.

тогда какого ЦУП и профайлер показывают таймаут а не дедлок

(0) потому что взаимоблокировки это не нормально. они дольше держат ресурсы заблокированными. а откат транзакции это тоже не нужная нагрузка на скуль сервер.

(5) потому что на сервере не происходит взаимоблокировки, а отваливается ожидающая сессия по таймауту

+(7) когда вы видите "таймаут"

а кто-нибудь пытался смоделировать дедлок и увиедть его в ЦУПе? Запускал одновременно 20 пользователей через тест-центр, и все выполняли один код с повышением уровня изоляции транзакции по взаимопересекающимся ресурсам - результат : превышение ожидания времени блокировки в транзакции, т.е. таймаут. Вообще сложилось впечатление, что для моделирования дедлока нужно очень сильно нагрузить сервер, просто так двумя десятками запросами не получится.

(0) ты чего там навоспроизводил? заставил ждать вторую транзакцию и ее выкинуло по тайм-ауту? это не дедлок вообще-то

(10) нет, вторая ждет когда первая освободиться, а первая когда вторая. Классический пример

(9) дедлок это определенная ситуация. при чем тут нагрузки вообще?

(12) А вот попробуйте воссоздать искусственно эту ситуацию, с двумя пользователями. Ситуация-то создается, но проблема в том, что сервер 2008 не регистрирует дедлок в профайлере, а считает это таймаутом

(13)а зачем мне создавать эту ситуацию? какой в этом смысл? ну создал, ну посмотрел, да дедлок. дальше что?

(11) он бы тогда и написал "дед-лок"

(15) а вот нифига. вот цитата с MSDN:Unlike Microsoft SQL Server, Microsoft SQL Server Compact 3.5 does not have deadlock detection. In SQL Server Compact 3.5, a deadlock is handled by using the lock time-out. If a transaction attempts to place a lock on a resource but cannot do so within the lock time-out, an error occurs. The lock time-out ensures that a transaction does not wait indefinitely for a resource held by another transaction. You can modify the lock time-out. For more information, see Lock Time-out.

If two transactions are involved in a deadlock, one of the transactions waiting for the resource times out and an error occurs. The transaction that times out is still active; it is not committed or rolled back. The other transaction then acquires the lock it requires and continues.

For more information, see SQL Server Books Online.

я так понял это спицифика 2008, 2005 бы написал deadlock

(14) чтобы было понятно, просто в ЦУПе захотелось отловить взаимоблокировки, на рабочих базах нет, да и не разрешают, вот и попробовал сам смоделировать, второй день мучаюсь, в итоге одни таймауты

(16) а причем тут Server Compact 3.5? или у тебя на ней база крутится? О_о

(0) В SSMS выполнить:
CREATE TABLE ##t1 (a int, b int, c int)
INSERT INTO ##t1
SELECT 1,2,3
UNION SELECT 2,3,4
UNION SELECT 3,4,5

CREATE TABLE ##t2 (a int, b int, c int)
INSERT INTO ##t2
SELECT 1,2,3
UNION SELECT 2,3,4
UNION SELECT 3,4,5

В новой сессии (1) выполнить:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
UPDATE ##t2
SET c = 2


В новой сессии (2) выполнить:
BEGIN TRANSACTION
UPDATE ##t1
SET c=1

В сессии (1) выполнить:

SELECT *
FROM ##t2

В сессии (2) выполнить:

SELECT *
FROM ##t1

В одной из сессий насладиться:
Msg 1205, Level 13, State 56, Line 2
Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Как смоделировать в 1С думай сам

(20) не все скопировал:

В новой сессии (2) выполнить:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
UPDATE ##t1
SET c=1

(18) про сифилис и триппер я думаю ты тоже слышал. не хочешь отловить их что бы понять что это такое? )))