Классика баз данных - статьи

       

Семантические особенности операций XQuery и XUpdate


В этом разделе мы обсуждаем семантические особенности XQuery и XUpdate операций, которые необходимо учитывать при разработке протокола изоляции XML-транзакций. Эти особенности влияют на выбор типов синхронизационных блокировок, требуемых в протоколе изоляции XML-транзакций, на котором основывается SXTM.Cемантические особенности операций состоят в следующем:

  • LP. Путевое выражение (locpath) является базовой конструкцией, используемой как в XQuery, так и в XUpdate. Поэтому для получения наилучшей гранулированности блокировок в протоколе должна максимально учитываться семантика locpath-выражений. Locpath состоит из последовательности шагов, на каждом из которых требуются различные типы блокировок. Например, на последнем шаге выбираются узлы, содержимое которых сериализуется [] и передается пользователю. Поэтому для таких узлов необходимо установить блокировку на чтение для поддеревьев (глубокую блокировку) с корнями в этих узлах. С другой стороны, для узлов, выбираемых на промежуточных шагах, достаточно установить блокировку на чтение только самого узла (неглубокую блокировку). В дополнение к этому, необходимо гарантировать, что не удерживаются глубокие блокировки на запись на поддеревьях, включающих узлы или поддеревья, которые мы хотим заблокировать на чтение. Эта проблема решается при помощи блокировок намерения (intention), которые выставляются на каждого предка рассматриваемого узла до установки блокировки на сам узел. Если в шаге есть предикат с операциями (например =, <, >), для которых нужно производить атомизацию [], то атомизируемые узлы также должны подвергаться глубокой блокировке на чтение.
  • Q. Запросы на XQuery обращаются к данным при помощи путевых выражений. Поэтому блокировки должны выставляться на основе путевых выражений (их семантические особенности обсуждались в предыдущем пункте). Но при этом они не должны рассматриваться изолированно от всего выражения XQuery, поскольку иначе теряется дополнительная семантика, которая позволяет улучшить гранулированность блокировок.
    Дело в том, что в выражении XQuery не для всех узлов, выбираемых locpath, требуется блокировать все поддерево. Например, в выражении fn:count(&#x002F;&#x002F;person) необходимо гарантировать неизменяемость количества узлов person, но при этом потомки элементов person могут изменяться произвольным образом другими транзакциями. В качестве еще одного примера рассмотрим FLWR-выражение: for &#x0024;v in &#x002F;&#x002F;person return &#x0024;a&#x002F;name. Здесь блокировки не обязаныобеспечивать неизменяемость всех поддеревьев person. Вместо этого достаточно гарантировать, что сами элементы person не будут никак изменены другими транзакциями (при этом потомки могут изменяться), и что не будут изменены поддеревья name.
  • II. Операция вставки нового узла в позицию последнего дочернего узла каждого целевого узла вызывается с двумя аргументами: выражение locpath специфицирует целевые узлы, а выражение constr2 определяет новый узел. Блокировки для locpath мы обсуждали выше. Для новых узлов необходимо установить неглубокую блокировку на запись. Например, для нового узла <person&#x002F;> требуется установить монопольную блокировку только на узел person, но при этом не нужно блокировать узлы, находящиеся ниже в иерархии. Для узла <name>John<&#x002F;name> имеются два варианта блокировок: можно установить монопольную неглубокую блокировку на узлы name и text (ребенок name) либо монопольную глубокую блокировку на узел name. Дополнительной семантической особенностью операции II является следующее: при вставке нового узла в позицию последнего дочернего узла целевого узла необходимо гарантировать, что другие транзакции не будут вставлять другие узлы на это же место. Очевидно, что можно установить глубокую блокировку (на чтение) на узел, в который вставляется новый узел, и тем самым гарантировать, что в него не будут вставлены новые узлы, но это слишком грубое решение. Здесь лучше ввести новый тип блокировок: неглубокую блокировку на чтение, которая дополнительно предотвращает вставку новых узлы в блокируемый узел.


    Аналогично для операций IA и IB требуется ввести неглубокие блокировки на чтение, которые дополнительно предотвращают вставку новых узлов после или перед блокируемым узлом соответственно. В остальном к операциям IA и IB применимы те же рассуждения, что и к операции II.
  • D. Операция D выполняет глубокое удаление целевых узлов. Поэтому необходимо запретить чтение или модификацию удаляемых поддеревьев другими транзакциями. Следовательно, на удаляемые узлы необходимо установить монопольную глубокую блокировку.
  • RN. Операция переименования присваивает новое имя узлу, но при этом не изменяет его потомков. Поэтому нужно установить монопольную неглубокую блокировку на изменяемый узел, а также на узел с новым именем. При этом не требуется устанавливать блокировки на потомков переименовываемого узла. В результате, например, транзакции Rename (&#x002F;doc&#x002F;person, person2) и &#x002F;doc&#x002F;&#x002F;name не будут конфликтовать по блокировкам.



Содержание раздела