Не могу придумать, как смоделировать сие.
При этом режим блокировки конфы управляемый и без программных блокировок

ап

Два документа с прямым и обратным порядком проведения по нескольким регистрам.

(2) Тут максимум что будет - это превышено время ожидания транзакции

(3) как раз дедлок и будет

(4) в (0) "При этом режим блокировки конфы управляемый и без программных блокировок"
Точно ли ?

(5) ну регистры то лочаться при записи по любому

(6) Только на время чтения/записи

конфа: http://dl.dropbox.com/u/67530172/1Cv8.dt

запускаешь 2 сеанса, один из них в отладке

ставишь в одном доке точку останова после записи первого регистра, проводишь док, чтоб встало на нее

во втором сеансе запускаешь проведение второго дока,

как там все подвисает, F5 в отладчике - http://screencast.com/t/E6Geve28kGdp

режим транзакции ведь READ-WRITE по-любому

(8) Спасибо

(10) обращайся, чо =)

(11) В файловов и серверном варианте уровни изоляции одинаковы?

(12) http://screencast.com/t/gKCENQj80sf7

(12)  разные, насколько я помню

(9) че за режим такой?

(15)разрешены чтение и модификация записей

а два READ-WRITE в один момент времени существовать не могут

(13) Ну значит если убрать автоматическую очистку движухи и принудительную запись наборов записей - то в скуле блокировка не возникнет (по крайне мере исходя из твоего пример)

(18) должно возникнуть, если по одному и тому же набору измерений писать

(19) Думаешь возникнет? Движуху то мы отдаем 1с записывать

(20) ну чтоб наверняка, можно еще проверку на отрицательные значения воткнуть после каждой записи... залочит по набору с вероятностью в 146%.

Так же по умолчанию скуль вроде б по диапазону лочит, это если не прописывать блокировку данных в 1Ске.

а вообще от анализа дедлоков на теоретическом уровне у меня крышу сносит постоянно

(21) В твоем примере дедлок вознкает потому, что в каждом документе дважды принудительно записываем набор записей. Если между этими записями вклинится - то пичаль, т.в файловом варианте блокировки накидываются на таблицу.

Если же сделать как в (18).. То наборы записываются один раз. Перехлеста не будет.. Плюс в скуле блокировки на запиь и считывание данных запросом блокировку не делает

(22) >>считывание данных запросом блокировку не делает

делают. Защита от фантомов.

Если убрать принудительную запись наборов, то дедлоков есессно не будет, так как не будет взаимозахвата ресурсов, и этого дедлока даж в файловой не будет

(23) Read commited, но после отработки запроса она снимается

(24) пофик когда снимается, главное, что ставиться и может привести к пичальке

(25) Не могу придумать как такое возможно

(26) у меня было, простой запрос с ГДЕ таблица.Реквизит = &Реквизит лочил таблицу при чтении. Решилось тогда добавлением индекса на этот реквизит. Чо там происходило уже не помню

(27) Он и лочит.. но не до дедлока. а индекс добавил - просто быстрее данные полуать стал

(28) разница в скорости там была незначительная, а ЦУПом и тест-центром я это дело нормально так гонял - до 50 одновременных потоков в одни и те же данные. и там был точно дедлок, а не таймаут

то, что в 2005 было deadlock d 2008.. - timeuot

Подниму тему..
В серверном варианте без программных блокировок так и не удалось дед-лок получить