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

Взаимное влияние пользователей, отрицательно сказывающееся на параллельности, определяется двумя факторами – количеством блокировок при обращении пользователей к одним и тем же данным, приводящим соответственно к ожиданию, и временем выполнения операций, то есть временем ожидания другими пользователями освобождения ресурсов.

Основных способов обеспечения параллельности соответственно два:

• минимизация конкуренции пользователей при записи данных (блокировок);

• снижения времени операций выполняемых в транзакциях.

Таким образом, при разработке структур данных и алгоритмов обработки данных необходимо обеспечить, чтобы, с одной стороны, при выполнении конкурентных действий блокировалось бы минимальное количество данных, которые могут быть нужны другим пользователя, а с другой стороны, чтобы транзакции, в которых происходит блокировка, выполнялись бы как можно быстрее.

Заметим, что здесь речь идет о транзакционных блокировках, поддерживаемых системой автоматически при считывании и записи данных в транзакции.

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

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

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

Разумеется, если производится оперативное проведение, приводящее к списанию одного и того же товара с одного и того же склада, то блокировка должна выполняться, так как именно блокировка и обеспечит невозможность повторного списания одного и того же товара. Однако если происходит списание различных товаров или с различных складов, то ни запись документа, ни запись движений регистров не должны приводить к блокировке и нарушению параллельной работы пользователей. При проектировании структур данных конфигурации и реализации алгоритмов обработки данных необходимо проверить, что не выполняется каких-либо дополнительных действий с данными, нарушающими параллельность.

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

При тестировании параллельности следует учитывать, что Microsoft SQL Server при выполнении блокировок записей таблиц может выполнять блокировку соседних записей. Соответственно при тестировании параллельности нужно обеспечивать реальное количество записей с различными значениями в ключевых полях, чтобы данные, блокируемые различными пользователями, не оказывали в тестовых примерах большего влияния друг на друга, чем в реальной базе данных.

Следует учитывать, что применение оператора ДЛЯ ИЗМЕНЕНИЯ в запросах, считывающих в транзакциях данные, которые предполагается модифицировать, позволяет уменьшить количество взаимных блокировок и сократить количество действий в транзакциях, которые будут откатываться из-за отмены транзакций.

С точки зрения ускорения выполнения транзакций кроме обычной оптимизации запросов и алгоритмов, выполняемых в транзакциях, следует проанализировать, не выполняются ли в транзакциях, например, при проведении, лишних действий, которые логически не связаны с самим действием, выполняемым в транзакции. Совершенно неприемлемым решением является использование в транзакциях каких-либо интерфейсных решений, останавливающих работу системы, например, выдачи пользователю предупреждений или вопросов.

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

Дополнительно рекомендуется ознакомиться с разделами "Особенности блокировок регистров при работе с 1С:Предприятием 8 в варианте клиент-сервер" и "Влияние взаимных блокировок на работу прикладного решения".