Да, действительно вопрос не новый. И есть несколько рекомендаций "смягчающих" данную проблему. Большинство из них были высказаны в теме форума на "mista".
Первый раз мы столкнулись с этой проблемой в 2000 года при внедрении "самописной" конфигурацию на своём предприятии. Тогда пришлось решать проблему путем сплошной замены ВСЕХ методов (термин из "объектного" программирования) обновления информации в базе данных на "свои" функции. В этих функциях производилась нормальная проверка блокировок. Пришлось переделать ВСЕ диалоговые формы ввода информации путем замены штатных кнопок "Новая строка", "Изменить", "Копировать строку" и т.д. на "свои" кнопки с вызовом "своих" функций. Работа по замене методов на функции не заняла много времени, т.к. конфигурация была полностью "самописная". И эта "самописность" была направлена на полный отказ от однопользовательских (и не имеющих никакого отношения к реальной жизни) таких понятий как: ось времени, точка актуальности, последовательность документов, проведение документа, регистры, получить итоги на..., монопольные регламентные функции и т.д. И, именно, сама "самописность" и породила проблему "ошибок транзакций", т.к. мы отказались от штатных механизмов платформы для хранения информации. Вся наша система сделана на справочниках.
В идеи "1С 7.7" не предполагается никаких других способов работы с информацией, кроме как в диалоговых формах и путем проведения (обновление регистров и проводок) документов. И попытки расширить предлагаемую схему путем, например, даже обновлением справочника в модуле проведения документа уже приводит к проблемам.
Суть и причины принятого алгоритма управления блокировками и транзакциями разработчиками 1С понятна и оправдана. Невозможно разработать универсальную и простую (для проблемного программиста) платформу не реализовав скрытый от программиста и простой алгоритм управления блокировками и транзакциями. И такой механизм единственный - обеспечить строгое последовательное выполнение транзакций. Т.е. в один момент времени может выполнятся только одна транзакция с уровнем изоляции "Serializable". Но при таком механизме необходимо обеспечить выполнение всех транзакций по единым правилам (алгоритмам). Но, например, в 1С для проведения документов используется в качестве "семафорной" блокировки таблица 1SJOURN (Журналы документов), а для обновления справочник сама таблица справочника. Что неизбежно приводит к явлению "Взаимная блокировка (deadlock)". Простого (встроенного) способа обработки и выхода из данного явления в 1С не существует, кроме как аварийное завершение транзакции по истечению времени ожидания. И если в диалоговых алгоритмах выдаётся вопрос пользователю с предложением повторить транзакцию или отменить, то в коде на встроенном языке выдаётся сообщение об ошибке и выполнение алгоритма аварийно прерывается. Естественно, проблемный программист может (и должен) обеспечить обработку аварийного завершения алгоритма, а лучше придумать и внести во всю конфигурацию инструмент обеспечивающий адекватное поведение системы. Но, если этого не сделали, даже, проблемные программисты типовых конфигураций (сотрудники фирмы "1С"), то что можно ожидать от программистов "самописных" конфигураций?
Занимаясь разработкой "DBEng32 Advantage/CodeBase" было принято и реализовано решение по синхронизации выполнения транзакций путем блокировки единого, для всех транзакций, ресурса. И все транзакции выполняются строго последовательно. Такое решение имеет минусы. Например, при долгом проведении документа, другие пользователи вынуждены ожидать её завершение даже если требуется выполнит обновление элемента справочника. Но, поведение системы становится более устойчивым и предсказуемым. Естественно, другой минус - это переход на другую СУБД и использование малоизвестной (моей) разработки подмены "родного движка" 1С-а.
В ходе переписки с автором темы форума на "mista" у меня возникла мысль обеспечить последовательное выполнение транзакций в "DBEng32 Share" //infostart.ru/public/16268/ Это стало возможным после включения в неё средства LockDB для выполнения OnLine копирования базы данных. И начиная с версии 8.0.1.1 такой инструмент, будет включен в данную разработку.
Для активизации инструмента:
1) Необходимо обеспечить наличие файла "1SxTTS.lck", как описано в //infostart.ru/public/86647/
2) Установить переменную среды текущего процесса:
SET DBEng32_Exclusive=1
Установка данной переменой в единицу "заставляет" сессию 1С запускать транзакции только если не существует в системе других активных транзакций. И не даёт запустить транзакции другим сессиям до завершения собственной транзакции. При этом, совсем не обязательно чтобы все сессии 1С работали по этим правилам. Например, можно установить эту переменную на нескольких рабочих станциях являющимися (по смыслу эксплуатации) критичными к эксклюзивному выполнению транзакций. Или, в случае использования терминал-серверного режима можно установить эту переменную в среде окружения конкретного пользователя (только для этого пользователя) или для всех пользователей в "System variables".
Не гибкие блокировки в "1С:Предприятие 7.7", но чуть-чуть "Управляемые".
База данных - HighLoad оптимизация
Автор темы: "DennizzM".
Название: "v7: 1c v7.7 ошибки транзакции - как отловить виновника?"
Текст с сокращениями:
"Вопрос наверняка не новый... Итак - есть база 1c v7.7 (самописная конфа). Периодически у пользователей возникает ошибка при проведении транзакции. База работает под терминалом. Нагрузка на дисковую подсистему небольшая, CPU на нуле, RAM до черта свободного. Вопрос вот в чем - как отловить инициатора первой транзакции которая всех держит? Итак - как мне выкрутиться? ;) ...я не имею права и не могу лезть внутрь конфы и модифицировать ее.".
См. также
1 стартмани
12.01.2014 23365 80 by_1Cnik 7
1 стартмани
07.05.2011 35056 165 si4 15