Периодически всплывает такая проблема, может пару месяцев не всплывать, но иногда таки проявляется. Причем «отпускает» тока если прибью все сессии на серваке, пробовал и 10 минут ждать — не отпускает. Как можно выяснить кто именно блокирует?

Скорее всего, кто-то перепроводит документы задним числом.

(1) вряд-ли, предложение восстановить последовательность при формировании отчетов - отключено. Обработки подобные есть тока у меня, да и права на проведение задним числом буквально у неск. человек

(2) Начни с mlg-файла... Уточняй время, когда все тормозило и смотри, кто что делал в это время.

хм, гляну, когда в след раз поймаю.

v7: 1С 7.7 SQL база то тормозит, то не тормозит
пост 17

(5) блин база дбф...

смотри в момент блокировки файлы лск, по ним можно понять какие обьекты открыты дальше в лог...

(6) а где их искать?  В каталоге с базой тока 1Cv7.lck

Попробуйте посмотреть на загрузку процессора если речь идет о терминальном сервере. Обычно во время массового перепроведения 1С отжирает всю доступную мощность процессора. В диспетчере задач видно какому пользователю принадлежит буйный процесс.

(8) не всю, а только одного ядра.

Я на ТиС в ДБФ на 5-6 рыл сделал такое извращение:

Создал 2 константы: пользователь транзакции и описание транзакции.

В обработчиках проведения и записи документов и справочников прописал проверку этих констант. Если значение констант не пустое, сообщаем, что такой-то пользователь проводит такой-то документ или редактирует элемент справочника и предложение повторить позже.

Многие проблемы с транзакциями и сопутствующие вопросы отпали.

(10) это не наш метод.

(9) Ну вот и увидите чей процесс работает.

(10)У меня через внешние файлики сделано примерно тоже самое. Запись констант нагрузку на базу все равно дает

(10): пользователь может отломаться - константы остануться, и все кому нужен этот объект данных - пойдут курить.
кроме того, при попытке одновременной записи объектов данных разныз типо-видов выполняется одновременный захват разных файлов, и при этом в таких корнстантах может остаться некорректная запись при зависании/тормозе первого прописавшего.

(14) Константы обнуляются обработкой или при монопольном входе

+(15) И перед записью константы читаются. Если свободны - записываются данные текущего пользователя. Провелся документ - очищаются. Продублировал функционал платформы таким неспортивным методом.

(15): ух ты умник какой. ну-ка выгони всех если работа 24/7 и час остановки - потерь на пять твоих зряплат.
(16): а если НЕ свободны? ожидание? а при этом - иогло бы работать, потому что пишется в другую таблицу... не, нуачо, правильно, не хватает тормозов - созданим себе сами, соорудив из юзеров очередь на константу, ай, малацца!..

(17) Я писал про конкретное решение на конкретной базе при конкретных условиях.
Критика должна быть конструктивной. Подскажи свой вариант.

(7) смотри типа SC45762.$lk

(19) В Dbf-базе лочится сам файл - 1С служебные не создаёт - эти файлы создаются только в SQL-версии.
В dfb-бывает, что выполняется транзакция в каком-то документе (например, он проводится), а умный пользователь просто давит Esc (например, что-то на него упало) и на экране видим окно о прерывании кода, а все остальные "курят" и ждут, пока всё освободится.
Решением данной проблемы может быть только создание робота, который выполняет все проведения и прочие длительные операции - тогда (а) его не прервут в неудачном месте, (б) нет необходимости параллельного выполнения транзакций, так как они все выполняются поочереди.

(20) для нагрузочных операций проведения уже давно подумываю - при формировании документа он ставится в очередь на проведение...???

(21) Остается определить, как сказать юзеру, что документ не проведен - нет товара на складе

(22) А в чём проблема - задание на проведение - элемент справочника - в нём потом можно и результат посмотреть, также можно сделать "транспорт" для передачи сообщений об ошибках и т.п.
Товар же лучше резервировать в момент подбора - тогда не будет множественных попыток проведения и игры в угадайку.

Резервирование товара в момент подбора - это то же самое проведение... получить остаток, вычесть чужие резервы и т.д...

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