← На главную

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

Суть проблемы: конфликт блокировок при обмене

Механизм РИБ при формировании сообщения обмена требует монопольного доступа к объектам метаданных, которые были модифицированы или дополнены с помощью расширений. Когда количество узлов обмена превышает 30-50 единиц, а фоновые задания на отправку данных запускаются одновременно, возникает ситуация «гонки». Несколько потоков фоновых заданий пытаются захватить расширение для записи изменений, что приводит к блокировке на уровне платформы.

Шаг 1: Обновление технологической платформы

Первым и самым важным шагом является обновление платформы 1С. Разработчики признали проблему (ошибка №30174983), и исправление было включено в актуальные релизы. Проверьте вашу версию платформы и, при необходимости, обновитесь до следующих релизов (или выше):

• 8.3.17.1989
• 8.3.18.1334
• 8.3.19.838 (и выше)

Именно в этих версиях была пересмотрена логика блокировки расширений при параллельном создании сообщений для периферийных узлов.

Шаг 2: Оптимизация регламентных заданий и очереди обменов

Если обновление платформы не решило проблему полностью или у вас очень большое количество узлов, необходимо изменить стратегию выполнения обменов:

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

Шаг 3: Технические рекомендации по администрированию

Проанализируем дополнительные способы минимизации нагрузки на систему:

• Ресурсы сервера: Убедитесь, что сервер обладает достаточным количеством ОЗУ и производительностью CPU. Недостаток ресурсов увеличивает время выполнения транзакции записи в файл обмена, тем самым расширяя «окно уязвимости» для возникновения ошибки.
• Управление сеансами: Если обмен стабильно падает, рассмотрите возможность автоматизированного завершения сеансов, которые висят дольше установленного лимита, перед запуском регламентного задания обмена.
• Работа с патчами: При обновлении конфигурации через РИБ, старайтесь придерживаться следующей тактики: сначала удалите патчи (расширения) в главном узле, выполните обмен, обновите конфигурацию, и только после успешного обновления и синхронизации всех узлов устанавливайте новые патчи.

Мы рассмотрели основные причины и методы борьбы с блокировками расширений. Главная рекомендация — это переход на исправленные версии платформы, так как это устраняет корневую причину на архитектурном уровне. В дополнение к этому, грамотное планирование очереди обменов и слежение за состоянием серверных сеансов обеспечат стабильную работу вашей распределенной сети магазинов.