Способ хранения констант в 1С:Предприятие 8 менялся в зависимости от версии платформы. Так, в платформе до версии 8.2.14 (или платформах выше версии, но с включенным режимом совместимости 8.2.13 и ниже), константы хранятся в одной таблице СУБД, начиная с версии 8.2.14, для каждой константы создается своя таблица СУБД. Данное изменение было сделано для увеличения параллельности работы пользователей. Давайте рассмотрим подробнее механизмы хранения констант в системе 1С:Предприятие 8.
Подготовка базы данных
Во-первых, подготовим базу для нашего исследования. Для этого создадим пустую базу данных, в нее добавим 4 константы, а также 1 справочник. Константам назначим типы:
- «Константа1»: Строка, длина 10
- «Константа2»: Дата
- «Константа3»: СправочникСсылка.Справочник1
- «Константа4»: Составной тип данных: Строка, длина 10; Дата; СправочникСсылка.Справочник1
Во-вторых, создадим две простых обработки:
- Первая необходима для анализа способа хранения констант в базе данных. Суть этой обработки заключается в том, что необходимо вызвать платформенный метод ПолучитьСтруктуруХраненияБазыДанных(), а результат (таблицы базы данных, поля таблиц, индексы таблиц и поля индексов таблиц) вывести на форму обработки. Так же эту обработку можно скачать из статьи «Получение информации о структуре хранения базы данных в терминах 1С:Предприятие и СУБД».
- Вторая нам понадобится для анализа возможностей параллельной работы с константами. Ее можно скачать из вложений к статье (в конце статьи).
Платформа до версии 8.2.14, а также версии выше с включенным режимом совместимости 8.2.13 и ниже
Структура хранения констант
Как видно по структуре хранения, действительно, в СУБД создана одна таблица для хранения констант, называется она «Consts». Причем, структура этой таблицы такова, что каждая колонка таблицы отвечает за значение одной из констант. Дополнительно к этим полям, в таблице присутствует поле ключа записи «RecordKey». Здесь стоит упомянуть, что результатом метода ПолучитьСтруктуруХраненияБазыДанных() является все же не сама структура СУБД, а некоторая ее интерпретация (при выборе режима «В терминах 1С:Предприятие»).
Для того чтобы получить более глубокое понимание структуры таблицы на уровне СУБД, необходимо перейти в среду управления соответствующей СУБД (или переключить обработку в режим «В терминах СУБД»). В моем случае, для СУБД MS SQL Server, этим инструментом является Management Studio. Открыв структуру нужной таблицы, мы обнаружим, что реальная структура таблицы в СУБД очень похожа на ту, что выдал нам метод ПолучитьСтруктуруХраненияБазыДанных(). Отличие между этими структурами заключается лишь в том, что для поля Fld27 (Константа 4) в СУБД создано целых 4 поля (Fld27_TYPE, Fld27_T, Fld27_S, Fld27_RRRef)! Это связано со способом хранения платформой значений составного типа и в данной статье не рассматривается.
Как вы уже, наверное, догадались, поскольку значения констант хранятся в отдельных колонках, значит, в таблице существует только 1 запись с этими значениями. Это так же можно проверить выполнив простой запрос к данной таблице как на рисунке и получить в результате выборки только 1 строку.
Возможности по параллельной работе с константами
Обладая знаниями о работе механизма блокировок, а также подкрепив теорию практикой, можно сделать вывод о параллельность работы данного механизма:
В режиме автоматических блокировок
Конкурентная запись, а так же конкурентные операции записи и чтения констант могут выполняться только последовательно, даже если эти действия выполняются над разными константами. Конкурентное чтение может выполняться параллельно.
| Автоматический режим | Константа 2. Чтение | Константа 2. Запись |
|---|---|---|
| Константа 1. Чтение | Параллельно | Последовательно |
| Константа 1. Запись | Последовательно | Последовательно |
В режиме управляемых блокировок
Конкурентная запись может выполняться только последовательно, даже если действия выполняются над разными константами. Конкурентное чтение может выполняться параллельно. Вопрос с конкуретными операции записи и чтения констант не так прост как кажется на первый взгляд. Поведение системы будет зависеть от порядка действий: запись, потом чтение; или чтение, потом запись. Также влиять будет фактор того, изменяется ли в действительности значение константы при записи или остается тем же (причина такого поведения мне не понятна, если Вы знаете почему — напишите в комментариях). И, конечно же, от наличия явных управляемых блокировок — т.к. с помощью данного механизма разработчик явным образом меняет поведение системы, будем считать что явные блокировки не устанавливаются. В этом случае параллельность работы будет представлена следующим образом: если модификации значения константы в действительности не происходит, тогда возможны параллельная запись и чтение. Если модификация константы происходит, но сначала выполняется чтение, а затем запись — параллельная работа возможна. В оставшемся случае, когда происходит модификация значения константы и сначала происходит запись, а потом чтение — возможна только последовательная работа.
| Управляемый режим | Константа 2. Чтение | Константа 2. Запись |
|---|---|---|
| Константа 1. Чтение | Параллельно | Особые условия (см. выше) |
| Константа 1. Запись | Особые условия (см. выше) | Последовательно |
Платформа с версии 8.2.14 без режима совместимости (или с совместимостью выше 8.2.13)
Структура хранения констант
Как видно, в отличие от платформы 8.2.13, для хранения каждой из констант создается своя таблица в базе (Const30, Const31, Const32, Const33). Как мы можем догадаться, это лучшим образом скажется на параллельности работы, будут ликвидированы «узкие» места связанные с записью разных констант.
Теперь перейдем к просмотру структуры в СУБД, как и для платформы версии 8.2.13, мы видим, что отображение структуры хранения на уровне платформы и на уровне СУБД схожи за тем исключением, что поле составного типа на уровне платформы отражается как единое целое, в то время как на уровне СУБД задействовано несколько полей.
Количество записей в каждой из таблиц не изменилось (в каждой таблице 1 запись), что можно проверить методом, аналогичным первой части.
Возможности по параллельной работе с константами
Вследствие изменения структуры хранения констант, любые действия с разными константами могут выполняться параллельно. Таким образом, ограничения на параллельную работу будут только для констант одного вида. Помимо этого, появилось еще одно свойство, влияющее на параллельность работы — для платформы 8.3 на уровне СУБД была включена возможность использования нового уровня изоляции транзакций — Read Committed Snapshot.
В режиме автоматических блокировок
Конкурентная запись, а так же конкурентные операции записи и чтения констант, могут выполняться только последовательно. Конкурентное чтение может выполняться параллельно.
В режиме управляемых блокировок (без Read Committed Snapshot)
Конкурентная запись может выполняться только последовательно. Конкурентное чтение может выполняться параллельно. Аналогично платформе 8.2.13, вопрос конкурентной записи и чтения зависит от порядка действий, а так же изменяется ли значение константы. Если модификации значения константы в действительности не происходит, тогда возможны параллельная запись и чтение. Если модификация константы происходит, но сначала выполняется чтение, а затем запись — параллельная работа возможна. В оставшемся случае, когда происходит модификация значения константы и сначала происходит запись, а потом чтение — возможна только последовательная работа
В режиме управляемых блокировок (c Read Committed Snapshot)
Запись одной константы только последовательно. Конкурентное чтение, а также конкурентные операции записи и чтения могут выполняться параллельно вне зависимости от порядка действий.
Практическая проверка материала
Для практической проверки материала предлагается воспользоваться простой обработкой в созданной ранее базе данных. Обработку можно скачать из вложений к статье. Ее необходимо открыть в двух сессиях нашей базы и произвести конкурентные операции. Результат выполнения должен быть таким же как в данной статье.