Параллелизм и блокировка

Для поддержания целостности данных все системы управления базами данных (РСУБД) применяют блокировки данных. Например, когда один пользователь начинает обновление строк, эти строки блокируются, чтобы предотвратить их изменение другим пользователем. По завершении транзакции блокировка прекращается.

Каждая СУБД использует блокировки и интерпретирует уровни изоляции по-разному. Более того, ArcGIS работает со всеми СУБД различным образом. В результате, возможные проблемы конкурентного использования при выполнении неверсионного редактирования слегка отличаются в различных РСУБД. В данном разделе приводится краткая информация о том, каким образом параллелизм и блокировки используются в рамках работы ArcGIS. Более подробно см. в документации по своей СУБД.

ArcGIS и уровни изоляции

При редактировании базы геоданных Oracle, DB2 или Informix в неверсионной сессии редактирования в работу включаются те же самые лежащие в основе СУБД механизмы блокировки, что и при работе с любым другим приложением — ArcGIS не изменяет режим работы этой среды путем установки уровня изоляции. Вместо этого используется текущий уровень изоляции, установленный в СУБД. В результате, вы можете установить для изоляции любой уровень и установить опцию использования этого уровня при выполнении редактирований в неверсионной сессии редактирования.

При редактировании базы геоданных SQL Server в неверсионной сессии редактировании ArcGIS устанавливает для уровня изоляции значение UNCOMMITTED READ до начала выполнения каждой транзакции. Вы никак не сможете изменить или обойти эту модель поведения:если вы установите для изоляции другой уровень до начала транзакции, то ArcGIS все равно установит значение UNCOMMITTED READ до начала выполнения транзакции.

В последующих разделах описываются возможные проблемы с явлением параллелизма, которые могут возникнуть при стандартных условиях. Пока не будет указано иное, в данных разделах подразумевается, что в используемой СУБД для уровня изоляции по умолчанию установлено COMMITTED READ или эквивалент этого значения.

Oracle

Редакторы блокируют редакторов: при выполнении операции редактирования одного пространственного объекта или группы объектов, например при их перемещении или изменении их атрибутов, СУБД блокирует строки их таблиц. Объекты будут заблокированы до тех пор, пока вы не сохранитесь или не завершите сессию редактирования, не сохраняясь. Соответственно, любой редактируемый пространственный объект или запись остается заблокированным на протяжении всего сеанса редактирования.

Когда два пользователя пытаются редактировать один и тот же объект в одно и то же время, объект блокируется, когда первый пользователь завершает операцию. Эта блокировка будет удерживаться, даже если этот пользователь начал работать совсем с другими объектами. Объекты будут заблокированы до тех пор, пока вы не сохранитесь или не завершите сессию редактирования, не сохраняясь.Следовательно, любой объект или запись, которые вы будете редактировать, будут заблокированы на период вашей сессии редактирования.

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

Два пользователя одновременно редактируют одно и то же.

• Пользователи изменили записи в своих текущих сеансах редактирования.
• Каждый из пользователей пытается изменить запись, уже измененную другим пользователем.
• У первого пользователя, который попытается изменить заблокированную строку, будут отображены песочные часы, поскольку его сессия ArcMap ожидает снятия блокировки.

Как только второй пользователь попытается изменить строку, заблокированную первым пользователем, возникнет ситуация, которая известна как взаимоблокировка (или тупик) (deadlocking): ситуация, при которой оба пользователи заблокировали друг друга. СУБД выведет для одного из них сообщение о необходимости в произведении отката транзакций, чтобы другой пользователь смог продолжить работу. Пользователь, транзакции которого были отменены, должен повторно внести все изменения, сделанные после момента последнего сохранения.

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

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

DB2 и Informix

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

Редакторы блокируют пользователей: в СУБД DB2 и Informix редакторы запрещают другим пользователям считывать те же самые данные на любом уровне изоляции выше UNCOMMITTED READ. На этих более высоких уровнях изоляции выполнение блокировки данных до момента сохранения редактирований или момента их отката может вызывать проблемы, связанные с процессом параллелизма:пока вы работаете в сессии редактирования, никто кроме вас не сможет считать данные, которые вы редактируете. Это может вызвать появление следующих ситуаций:

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

Пользователи блокируют редакторов: в СУБД DB2 и Informix пользователи могут запретить другим пользователям изменять те же самые данные на любом уровне изоляции выше UNCOMMITTED READ. Однако на практике вы редко когда сможете заметить это в ArcGIS, поскольку устанавливаемая при чтении данных блокировка строки длится очень малое время:к тому времени, когда данные будут отображены, блокировка уже будет снята. Пользователи, считывающие данные, по-настоящему смогут заблокировать редакторов в приложении, которое откроет курсор в СУБД, извлечет одну строку за раз и затем проведет итерацию через выборку, обрабатывая данные. В этом случае DB2 и Informix будут запрашивать и удерживать блокировки, когда будет происходить процесс обработки выборки.

PostgreSQL

Редакторы блокируют редакторов: в PostgreSQL невозможно обновить запись до тех пор, пока первая внесшая изменения транзакция не будет отправлена в базу данных или отменена. Если два пользователя пытаются редактировать один и тот же пространственный объект одновременно, первый из них блокирует обновления этой записи. Другие пользователи не могут редактировать эту запись до тех пор, пока первый либо не сохранит изменения (т.е. отправит изменения в базу данных) или не выйдет из сеанса редактирования без сохранения изменений (т.е. отменит все изменения своего сеанса редактирования).

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

Редакторы не блокируют пользователей: если вы используете в PostgreSQL мультиверсионный контроль общего доступа (multiversion concurrency control, MVCC), который установлен по умолчанию и является рекомендуемым для баз данных, транзакции пользователей, что-то записывающих в базу данных, не блокируют доступ для чтения остальным пользователям. Это верно при использовании уровня изоляции по умолчанию READ COMMITTED в базе данных или установке уровня изоляции SERIALIZABLE.

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

SQL Server

ArcGIS будет устанавливать для уровня изоляции значение READ UNCOMMITTED до начала каждой транзакции в базе геоданных SQL Server. Ниже приводится информация о том, какие проблемы, связанные с параллелизмом, могут возникнуть в рамках работы ArcGIS. Для получения более подробной информации об уровне изоляции READ UNCOMMITTED см. документацию по СУБД SQL Server вашей версии.

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

Редакторы не блокируют пользователей: поскольку ArcGIS устанавливает для уровня изоляции значение READ UNCOMMITTED до начала выполнения каждой транзакции, пользователи, считывающие данные, не блокируют таких же пользователей в базах геоданных SQL Server. когда у вас имеется несколько пользователей, изменяющих данные, и несколько других пользователей, производящих считывание тех же данных, то для пользователей имеется возможность прочитать данные, которые были изменены, но еще не были зафиксированы. Это явление называют недействительным результатом чтения (dirty read) и его появление может привести к следующим последствиям выполнения запроса:

• Возвращению неточных значений данных
• Не возвращению данных при их существовании
• Повторному возвращению данных, которых уже не существует

Пользователи не блокируют редакторов: поскольку ArcGIS устанавливает для уровня изоляции значение READ UNCOMMITTED до начала выполнения каждой транзакции, пользователи, считывающие данные, не блокируют редакторов в базах геоданных SQL Server.

Предотвращение проблем многопользовательского доступа

К счастью, существует несколько путей минимизации риска появления проблем такого рода:

Разработка приложений и рабочих процессов с подразумевающейся блокировкой: необходимость ожидания разблокировки запросов часто является следствием действия неудачных приложений или рабочих процессов. При разработке надо убедиться, что блокировка запрашивается когда она действительно нужна. Вы можете добиться этого путем создания стандартов последовательности обновления по всем таблицам. Это должно помочь вам избежать появления взаимоблокировок (или тупиков) (deadlocks). Чтобы сократить количество удерживаемых блокировок, лучше всего сделать так, чтобы любые запросы на изменение данных применялись в конце единицы логики приложения или рабочего процесса, выполняющего транзакцию.

Установите необходимый уровень изоляции (Oracle, DB2, Informix): уровень изоляции влияет на время, которое транзакция будет блокировать данные. Чем выше уровень изоляции, тем дольше транзакция будет удерживать блокировку. Чем дольше транзакция удерживает блокировку, тем сильнее она увеличивает целостность данных, но за счет увеличения конкурентного использования. Если это приемлемо для ваших целей, вы можете сократить уровень изоляции.

Зарегистрируйте данные как версионные: повысьте параллелизм работы путем регистрации данных как версионных с опцией перемещения изменений в базовую таблицу. Это позволит пользователям продолжать обслуживание данных с приложениями, не используя ArcGIS, но добавит возможностей для пользователей приложений ArcGIS и ArcObjects, на которые в противном случае это имело бы влияние, или которые могли вызывать проблемы параллелизма для редактирования и управления версиями данных. Когда пользователь редактирует версию, они не используют блокировки, позволяя ему редактировать данные в полной изоляции от других пользователей.

Блокировка в базе данных представляет собой сложное явление. Более того, в каждой СУБД блокировка выполняется по-разному. Поэтому вам нужно изучить модель поведения каждой СУБД, чтобы определить, на каком уровне вам нужно установить блокировки, как лучше установить уровни изоляции и как избежать появления простоев при блокировке и взаимоблокировок (тупиков).См. также