Как организовать одновременный ввод данных множеством пользователей в 1С без конфликтов блокировок?

В процессе разработки высоконагруженных систем на платформе 1С:Предприятие часто возникает задача организации интерфейса для коллективного ввода данных. Типичный сценарий: существует некий объект (например, «Анкета» или «Тема»), в который должны одновременно вносить информацию десятки или даже сотни пользователей. Начинающие разработчики часто выбирают очевидный, но ошибочный путь — использование табличной части одного документа. В этой статье мы разберем, почему такой подход ведет к краху системы, и рассмотрим профессиональные методы реализации подобного функционала.

Проблема объектных блокировок и конкурентного доступа

Рассмотрим ситуацию, когда мы используем один Документ с большой табличной частью. Платформа 1С работает с объектами как с цельными единицами данных. Это накладывает серьезные ограничения при попытке записи:

1. Оптимистическая блокировка. Представим, что два пользователя открыли форму одного и того же документа. Первый пользователь добавил строку и нажал «Записать». Система успешно сохранила данные и обновила версию объекта в базе. Когда второй пользователь попытается нажать «Записать», он получит критическую ошибку: «Объект изменен или удален другим пользователем». Его версия документа в оперативной памяти устарела, и платформа блокирует запись, чтобы не затереть изменения первого пользователя.
2. Пессимистическая блокировка. Если мы попытаемся программно заблокировать объект (через Заблокировать()) в момент начала редактирования, то все остальные пользователи просто не смогут открыть документ на редактирование. Они будут видеть сообщение о том, что объект заблокирован другим сеансом.

Проанализируем ситуацию: если у нас «over много юзеров», как выразился автор вопроса, работа в таком режиме станет невозможной. Пользователи будут постоянно сталкиваться с ошибками записи, терять введенные данные и тратить время на перезаполнение форм.

Деградация производительности табличных частей

Помимо блокировок, существует технический аспект работы СУБД. Табличные части в 1С не предназначены для хранения сотен тысяч строк. Выясним причину:

При каждом чтении или записи документа платформа считывает или записывает всю таблицу целиком. Если в таблице накопятся тысячи записей от множества пользователей, каждое сохранение превратится в передачу огромного массива данных между сервером приложений и базой данных. Это вызовет колоссальную нагрузку на дисковую подсистему и сеть, а пользователи будут наблюдать «зависания» интерфейса при каждом нажатии кнопки сохранения.

Решение №1: Использование независимых Регистров сведений

Наиболее правильным и архитектурно верным решением в данной ситуации является использование независимого регистра сведений. Давайте разберем по шагам, почему это работает лучше:

• Построчная запись. В регистре сведений каждая запись (строка) является самостоятельной единицей. Когда пользователь вводит данные, мы записываем в базу не весь «документ», а только конкретный набор записей. Блокировка при этом накладывается только на уровне конкретных измерений, не мешая другим пользователям записывать свои данные в этот же регистр.
• Индексация данных. Регистры сведений оптимизированы для быстрого поиска и выборки по измерениям. Мы можем мгновенно получить все ответы по конкретной «Теме», не перечитывая лишние данные.
• Динамические списки. Для отображения данных в форме лучше всего использовать ДинамическийСписок, источником данных для которого выступает наш регистр. Он считывает данные порциями, что обеспечивает мгновенный отклик интерфейса даже при миллионах записей.

Рассмотрим пример кода для записи ответа пользователя в независимый регистр сведений:

// Процедура записи ответа в независимый регистр сведений
МенеджерЗаписи = РегистрыСведений.ОтветыПользователей.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Тема = ТемаСсылка;
МенеджерЗаписи.Вопрос = ТекущийВопрос;
МенеджерЗаписи.Пользователь = ПараметрыСеанса.ТекущийПользователь;
МенеджерЗаписи.Ответ = ТекстОтвета;
МенеджерЗаписи.ДатаЗаписи = ТекущаяДатаСеанса();

Попытка
    МенеджерЗаписи.Записать(Истина); // Истина — замещать существующую запись
Исключение
    Сообщить("Ошибка при сохранении данных: " + КраткоеОписаниеОшибки(ОписаниеОшибки()));
КонецПопытки;

Решение №2: Схема «Один ко многим» (множество документов)

Если бизнес-логика все же требует использования именно документов (например, для сложной цепочки согласования или проведения по регистрам бухгалтерии), следует изменить архитектуру с «один документ для всех» на «один документ на каждого пользователя».

Разберем этот метод подробнее:

1. Создается документ ОтветНаВопрос.
2. В документе создается реквизит (измерение), ссылающееся на «Темы» (родительский объект).
3. Каждый пользователь создает свой экземпляр документа. Конфликтов блокировок не возникает, так как каждый работает со своим объектом.
4. Итоговая аналитика собирается отчетом или виртуальной таблицей, которая объединяет данные всех документов по конкретной теме.

Решение №3: Временные таблицы и фоновая обработка

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

Данные от пользователей сначала записываются в «быстрый» буфер (это может быть временное хранилище, JSON в текстовом файле или очень простой независимый регистр). Затем специальное регламентное задание (фоновый процесс) раз в несколько минут считывает накопленные данные и одной транзакцией переносит их в итоговый документ или регистр. Это позволяет минимизировать количество транзакций к основной базе данных и полностью исключить ожидание блокировок для пользователей.

Выводы и рекомендации

Подводя итог, можно сказать, что попытка записи множества пользователей в одну табличную часть — это классический «антипаттерн». Чтобы ваша система работала стабильно и быстро, следуйте этим правилам:

• Всегда разделяйте данные по владельцам или транзакциям.
• Используйте РегистрСведений для хранения плоских списков данных, вводимых разными людьми.
• Для отображения больших объемов информации применяйте ДинамическийСписок.
• Помните, что Объектная модель 1С (Документы, Справочники) предназначена для монопольного редактирования записи одним пользователем в конкретный момент времени.

Правильный выбор архитектуры на начальном этапе избавит вас от необходимости переписывать систему в будущем, когда количество данных и пользователей вырастет.