Коллеги, добрый день. УПП, допиленная. Есть пару дэдлоков. Как разбирать дэдлоки на ИТС прочитал. Один поборол, с повышением уровня блокировки. Есть еще пра дэдлоков, при записи в РАУЗ. Они сложные, там 20 строк в дэдлоке (по сервису Гилева). + Сам РАУЗ для меня еще темный не совсем знаком.
Может есть какие-нибудь "лайвхаки", как легко дэдлоки разбирать?
P.S. понимаю, что темя "пятничная")

И еще вопрос, может, у кого-то есть идеи, как лучше передать механизм.
1)Перед записью в документе идет чтение по не типовому регистру сведений (в регистре 2 измерения "Документ" - документ - это регистратор, "Тара" - туда пишется реквизит документа. И Ресурс "Состояние" - туда пишется перечисление. То есть, по логике работы программы перед записью читается предыдущее состояние этой самой "Тары", в документ, который записывается, пишутся документы, которые изменяли эту же самую тару. То есть обязательно, чтобы алгоритм был перед записью, для модификации документа. Потом в обработке проведения, в этот регистр записывается эта самая "Тара".
Если по одной таре будет одновременно проводиться 2 документа в 2 разных сеансах, то 1 наложит блокировку на чтение и 2 на чтение, 1 попробует записать, но будет ждать 2, пока тот отпустит регистр, а 2 попробует записать, но он будет ждать 1... В общем, полностью попадает под описание проблемы с ИТС, о повышении уровня блокировки. Я добавил упр. блокировку по измерению "Тара" и перед чтением. Проблема ушла, но теперь эта блокировка в топе ожиданий на блокировках. У меня есть только идея, чтобы писать данные в сам документ перед записью, а писать, допустим, в новый регистр сведений(чтобы не городить лишний регистр можно получать всё из текущего регистра). Тогда можно отказаться от чтения перед записью и читать в обработке проведения. Тогда будет совсем небольшое ожидание. Есть один нюанс - переделывать алгоритмы поиска.  
Может, у кого-то есть блестящая идея?)
Хотя, я не огорчусь, если ответа на мой вопрос не будет. Заранее спасибо, что прочитали такую большую портянку

С блокировкой на чтение - не все так однозначно.
Зависит от релиза платформы и режима управления блокировками.

основные причины дедлоков 2:
Повышение уровня изоляции.
Захват ресурсов в разном порядке.
Вот и думай - что у тебя

(3) В автоматическом режиме -
Повышение гранулярности (эскалация)
Захват ресурсов в разном порядке

(4) Тьфу в управляемом конечно же

Первое с чего надо начать - понять пространства имен на которых это происходит.
Если есть не типовой РС неподчиненный регистратору - отказаться от использования работы с ним через НаборЗаписей.
Читаем - запросом.
Пишем - менеджером.

(6) Очень часто работы заканичваются уже тут, не далеко не всегда.
Анализ анализ и еще раз анализ.

(6) Совет писать через МЗ конечно хорош, но далеко не всегда выполним: у МЗ нет ни доп. свойств, ни режима загрузки :(

(8) А зачем эти палочки и костылики в транзакции?
Я могу понять их использование в обменах.
Но в транзакции наверное все таки не стоит.

(1)
1) какая-то странная архитектура... подумай в сторону периодики или регистра накопления, глядишь и дедлоки уйдут :)

(9) Что-то ты ортогональные понятия пытаешься противопоставить. В интеграциях с внешними системами чуть чаще, чем полностью, бывает надо что-то записать в БД согласованно (в единой транзакции) и быстренько, без проверок прикладного кода конфигурации.

(6) Блокировки разные будут в случае одной и той же записи РС Набором и Менеджером?

(12) Речь о ситуациях когда записей несколько. В случае с МЗ гранулярность всегда под контролем, в отличие от НЗ.

для начала переходить на упр блокировки и режим совместимости 8.3 (ну или просто режим версионирования включить).
Пото включить отложенное проведение.
90% проблем этим решится

(14) У нас нет отложенного проведения( Новерно, придется перенсети

у вас настолько древний релиз УПП?

(14) упр блокировки на самом деле не сложно ввести. там по сути 2 места только : Авансы и Остатки товаров

(16) Да, к сожалению и поднять его, навряд ли получиться, там доработок слишком много...

(17) А РАУЗ? Я хочу туда упр. блокировки в по хозрасчетному. Думаю, мб сейчас лочится весь регистр (упр. блокировок нет в коде, но у регистров стоит режим упр. блокировок)

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

(20) А если я не указываю измерения мне система по дефолту не блокирует весь регистр по всем измерениям?

в упп вообще блокировать бух регистр не нужно. там он вторичен

(0) какая версия УПП и что стоит в свойстве конфигурации "Режим упр. блокировкой данных"?

(23) Управление производственным предприятием, редакция 1.3 (1.3.36.1)
Режим упр. блокировки "Управляемый"

(24) так у тебя уже блокировки управляемые, тогда просо версионирование нужно включить на SQL

(24) выясни на каких документах и регистрах взаимоблокировка и установи упр. Блокировки в этих документах по этим регистрам исключительные упр. Блокировки.

(25) Так разве если я на уровне 1с не наложу упр. блокировку кодом - у меня весь регистр залочиться? или Скуль умный и не лочит всю таблицу, а по измеренииям идуб локировки на запись?

(25) А что за версионирование?

блокировки 1с никакого отношения к скулю не имеют

(26) Спасибо, но я так понял, это только в случае повышения уровня изоляции надо...

(30) Это на все случаи

(27) Если не наложишь кодом, то платформа все равно наложит за тебя: разделяемые при чтении (НЗ и объектов с ТЧ) и исключительные при записи

(28) RCSI в MSSQL

Менеджер записи - надстройка над набором записей. По сути это объект, записывающий при записи либо 2 набора (если после чтения менялись ключевые поля) либо 1 набор. К сожалению эта надстройка не имеет проброса свойств ОбменДанным и ДопольнительныеСвойства. Других методов записи у нее нет (только через наборы записей).