Каталог решений - Планы обмена 1С: решение проблемы блокировок при помощи средств SQL Server

Я поставил цель: улучшить работу планов обмена таким образом, чтобы внешне работа с ними со стороны 1С ничем не отличалась бы, но поведение механизмов платформы было бы другим. В частности, я хотел решить пресловутую проблему блокировок, которой страдают планы обмена. Достигнуть этих целей мне удалось. В результате получился тюнинг-пакет для планов обмена … в лучших традициях hard КОРа (костыль-ориентированной разработки) =) =) =)

Изучив то, каким образом работают планы обмена на уровне SQL Server, мне пришла в голову очень простая идея: а что если "подсунуть" 1С вместо таблицы регистрации изменений, например, _ReferenceChngR71, представление SQL Server (view). При этом поведение механизмов планов обмена 1С изменить при помощи INSTEAD OF триггеров этого VIEW …

Общая схема такой идеи выглядит следующим образом:

Ключевым моментом является понимание того, что должны делать триггеры, чтобы улучшить работу планов обмена, а именно решить проблему блокировок, которой страдают все высоко нагруженные системы, использующие этот механизм, особенно РИБ.

Идею решения этой проблемы я решил заимствовать у технологии SQL Server Change Tracking. О применении этой технологии совместно с платформой 1С я писал в своей статье "Использование SQL Server Change Tracking для регистрации изменений данных объектов 1С:Предприятие 8". В ней можно найти ссылки на дополнительные материалы.

Идея заключается в том, что каждое изменение объекта данных рассматривается как изменение версии этого объекта. Регистрируется каждое такое изменение при помощи команды INSERT. Эта команда, в отличие от UPDATE, которую использует 1С, не создаёт никаких блокировок. Всё очень просто. Графически эта идея может выглядеть следующим образом:

Мы имеем вектор изменений объекта данных V. На рисунке показано 10 версий таких изменений. Каждое новое значение версии генерируется при помощи таблицы SEQUENCE (см. рисунок выше).

Каждой версии соответствует запись в таблице регистрации изменений. На рисунке выше она называется CHANGES. Эта таблица по факту дублирует функционал таблицы регистрации изменений _ReferenceChngR71 плана обмена 1С, добавляя к ней поле [version]. Теперь каждому объекту соответствует несколько записей по количеству актуальных на текущий момент времени версий. Таким образом мы решаем проблему блокировок, которая возникает при долгом UPDATE’е когда вызывается метод "ВыбратьИзменения" планов обмена. При помощи триггеров мы эту команду просто игнорируем =)

Когда объект находился в состоянии версии 4 мы выполнили оправку данных. Это событие наша КОР система региструет в таблице SESSIONS (см. рисунок выше). Эта таблица устанавливает соответствие между нашими версиями и значениями номеров сообщений, которые генерирует план обмена. Теперь все версии до 4 включительно нам не интересны, если мы используем гарантированную доставку. Специальное регламентное задание может спокойно удалить их из таблицы CHANGES при этом абсолютно никому не мешая. Опять же решаем проблему блокировок при долгих DELETE’ах.

Теперь немного о механизме отправки сообщений. На рисунке мы начали отправку сообщения обмена методом "ВыбратьИзменения" плана обмена когда объект имел версию 8. В этот же самый момент времени пользователи успели изменить объект два раза и его текущая версия стала равна 10. Замечу, что при этом никаких блокировок не возникает: каждый занят своим делом и никто не мешает друг другу. После отправки изменений и фиксации тразакции в таблице SESSIONS версия 8 перейдёт в остояние "Отправлено", как до этого было с версией 4.

Вот вкратце и всё. Для тех, кто любит всё "потрогать руками" самостоятельно, детали реализации и примеры кода 1С и T-SQL находятся во вложенном к публикации архиву. Вопросы приветствуются. Постараюсь удовлетворить любое ваше любопытство по мере моих скромных сил =)