v7: Ошибка блокировки, при транзакции. Как выяснить кем? DBF #571974

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

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

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

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

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

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

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

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

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

Я на ТиС в ДБФ на 5-6 рыл сделал такое извращение: Создал 2 константы: пользователь транзакции и описание транзакции. В обработчиках проведения и записи документов и справочников прописал проверку этих констант. Если значение констант не пустое, сообщаем, что такой-то пользователь проводит такой-то документ или редактирует элемент справочника и предложение повторить позже. Многие проблемы с транзакциями и сопутствующие вопросы отпали.

это не наш метод.

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

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

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

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

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

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

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

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

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

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

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

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

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

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