В общем, есть один документ, он является регистратором только для одного регистра.
Используются управляемые блокировки: переписан код проведения, регистр переведен на упр.блокировку.
НО, если сотрудник делает проведение документа с кучей строк, и проведение затягивается по времени, то вешаются все. В консоли сервера вижу, что все стоят в очереди, именно те, которые работают с совершенно другими документами (к примеру, с кассовыми).
Но ведь документ не трогает другие регистры. В чем может быть дело?

Да, в качестве БД - используется Oracle. Конфа - УПП.

платформа?

1С:Предприятие 8.2 (8.2.15.301)

Управляемые блокировки точно ничего лишнего не блокируют?

(4) Вот кусок кода:

   Блокировка = Новый БлокировкаДанных;
   ЭлементБлокировки = Блокировка.Добавить();
   ЭлементБлокировки.Область = "РегистрНакопления.Полисы";
   ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
   ЭлементБлокировки.ИсточникДанных = ТзТч;
   ЭлементБлокировки.ИспользоватьИзИсточникаДанных("КлассификаторБСО", "КлассификаторБСО");
   ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номер", "Номер");
   Блокировка.Заблокировать();

документ в журнале используется?

(0) Документ в последовательность входит?
База распределенная (под сомнением влияние)?
В общие журналы документ входит (тут не уверен)?

(6) Есть отдельный журнал.

(7) В последовательность не входит.
Не распределенная.
В общие - ща гляну - не, только в отдельный журнал.

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

"переписан код проведения" - как он переписан если он новый и независимый?

(11) Вначале был в автоматическом режиме блокировки. Но вешались все, кто работал с этим регистром. Потом переписали. Стало намного легче.
Но иногда, иногда (раз в два дня) - документ вешает всех пользователей. И не пойму, почему это происходит.

(12) емнип в более поздних платформах (17-я вроде) было критичное обновление для Оракла, не вошедшее в описание исправленых ошибок. Было связано с жёсткими тормозами при удалении больщих временных таблиц

(13) Кстати, используется менеджер временных таблиц.

(13) Как меня радуют эти критические исправления, которые не входят в описания. Хрен потом найдешь что да как. :(

(14) Ну так обновляемся :)

(14) Временные таблицы потом принудительно уничтожаются. Попробовать их не удалять?

(16) Да, надо. Все собираюсь на 18 релиз перейти. Не глядя опасаюсь, а тестового сервера пока временно нет.

(14)(15) это почти инсайдерская инфа)
Суть там была в том что вместо аналога дропа таблицы - удалялись по одной записи.
(17) не уверен что поможет, ибо она всё равно будет удаляться платформой автоматически при уборке "мусора"

В общем на ум приходит только одно - обновлять платформу.

(20) это первое что надо сделать. С учетом того что было переписано - есть вариант что и не из-за этого... может ещё где косяк. В любом случае смысла сидеть на 15-й не видно

(21) ясно. Спасибо.

(0) может в планах обмена документ где-то засветился?

(23) проверил, в планах обмена документ не значится.

проведи эксперимент.

сделай обработочку в запросе в которой бет ВТ на 5-10 млн записей, и сделай там Уничтожить ВТ. Если юзеры "зависнут" то это оно и есть

а какие измерения у регистра? Я думаю, надо копать в сторону запроса и записи в регистр. Советую переписать код. 1C рекомендует делать контроль остатков так: записываем данные в регистр, проверяем остатки.

(26) Так и сделано: сначала пишется в регистр, потом идет проверка остатков.

Чаще всего документ проводится в четверть секунды. Но иногда происходит то, что написано в теме поста.

(26)
Измерения:
КлассификаторБСО - справочник КлассификаторБСО
Номер - число
МОЛОтветственый - справочник ФЛ
ПодразделениеОрганизации - справочник подразделения организаций
МОЛПолучатель - справочники ФЛ/Контрагенты

(27) ну тогда не знаю. Но все равно советую почитать
Блокирующее чтение остатков в начале транзакции

(29) В любом случае - другие документы тут причем? Ведь их регистры не затрагиваются.

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

(31) "далее посмотри: если проведется - значит действительно не блокируется, проблема где-то непонятно в чем, иначе - проблема в том что все-таки где-то блокируется твоим документом"


ого...

Сегодня такая блокировка произошла утром, повисли тупо все. Пришлось выбросить пользователя.
Ладно.. покопаемся.

(30) а может какая-то последовательность? Журнал документов и т.д. Для опыта советую убрать все ссылки на этот объект

(32) может, кто-то знает как узнать какая таблица заблокировалась?

(32) да это не долго и не трудно, не пугайся, нужна всего лишь тестовая база и 5-10 минут времени

(34) как вариант - ЦУП, реально поможет
или ТЖ (трудно, долго, не факт что поможет)
или аналог профайлера скуля (если конечно на оракле есть - я не знаю)

(35) Нюанс то в другом:
виснут другие документы, когда проводится наш проблемный документ. То есть надо его тормозить точкой останова.

(36) ЦУП с Ораклом дружит?

(32) это действительно очень просто

(38) как раз аналог профайлера скуля оракловский намного круче, им выявилась проблема с ВТ. проведи (25), если оно - то всё остальные вопросы снимаются

(38) может и нет, сорри))
остается тогда ТЖ и еще вроде у Гилева сервис есть (поищи на форуме и на ИС)

Спасибо за советы. Бум пробовать.

(42) результаты эксперимента на 15-й платформе огласи, интересно

(43) Я ветку добавил в избранное - как тестовый инстанс освободится - попробую.