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

в) Существуют ли какие-либо чередующиеся графики запуска, которые для заданного начального значения А Хнуль) приводят к получению корректного результата, но не допускают упорядочения?

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

15.4. Ниже приведена последовательность выполнения различных событий в фафике запуска с транзакциями Т1, Т2, Т12 и объектами базы данных А, В, Н.

Время to ........

Время tn ........

Предположим, что для выполнения оператора RETRIEVE R (считать R) требуется (в случае успеха) установить S-блокировку для объекта R, а для выполнения оператора UPDATE R (обновить R) требуется (в случае успеха) установить для объекта R X-блокировку. Допустим, что все блокировки сохраняются до конца выполнения транзакции. Возникнет ли ситуация взаимной блокировки к моменту tn?

15.5. Еще раз обратимся к проблемам параллельности, представленным на рис. 15.1-15.4. Что произойдет в каждом из этих случаев, если все транзакции будут выполняться на уровне изоляции Повторяемость считывания , а не на уровне Стабильность курсора ?

15.6. Дайте формальные и неформальные определения пяти типам блокировок: X, S, IX, IS, SIX.

15.7. Сформулируйте понятие относительной силы блокировок и нарисуйте соответствующую диаграмму их приоритета.

15.8. Сформулируйте определение протокола блокировки намерения, а также поясните основное назначение этого протокола.

15.9. В стандарте языка SQL определяются три проблемы параллельности: некорректное чтение, неповторяемое чтение и чтение фантомов. Как они соотносятся с тремя проблемами параллельности, описанными в начале этой главы (потери результатов обновления, зависимости от незафиксированных результатов и несогласованной обработки данных)?

15.10.Кратко опишите механизм реализации многовариантного протокола управления параллельностью, обсуждаемого в комментарии к [15.1].

Список литературы

в этом списке следовало бы также упомянуть работы [14.2], [14.10] и особенно [14.12] из главы 14.

15.1. Bayer R., Heller М., Reiser А. Parallelism and Recovery in Database Systems ACM TODS. - June, 1980. -- 5, № 2.

Как уже говорилось в главе 14, новые прикладные области (например, проектирование и разработка программного и аппаратного обеспечения) часто выдвигают сложные требования к обработке данных, которые нельзя полностью удовлетворить с помощью классических схем управления выполнением транзакций, описанных в этой и предыдущей главах. Основная проблема заключается в том, что сложные транзакции в этих прикладных областях могут продолжаться в те-

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

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

2. Использование обычных блокировок может иметь следствием появление чрезмерных задержек, вызванных ожиданием снятия блокировок требуемых элементов, что также неприемлемо.

В этой работе описьшается один из методов устранения подобных недостатков (см, также [15.7], [15.11]-[15.13], [15.17]), а именно- метод управления параллельностью, называемый многовариантной блокировкой (multi-version locking; иначе может называться многовариантным считыванием (multi-version read)), который уже используется в нескольких программных продуктах. Основное преимущество этого метода заключается в том, что операции считывания выполняются без вынужденного ожидания, т.е. любое количество операций считывания и одна операцш записи могут выполняться для одного и того же объекта одновременно. Точнее говоря, выполняются следующие правила.

Операция чтения всегда выполняется без задержки (как только что говорилось).

Операции чтения никогда не задерживают выполнение операций обновления.

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

Ситуация взаимной блокировки может возникнуть только между транзакциями обновления.

Указанные преимущества особенно важны для распределенных систем (см. главу 20), в которых на выполнение обновления данных может потребоваться значительное время, а потому выполнение запросов, включающих только операции чтения, может чрезмерно затянуться (и наоборот). Основную идею данного метода можно сформулировать следующим образом.

Если транзакция Т2 пытается выполнить операцию считывания объекта, для которого в данный момент выполняется обновление в пределах транзакции Т1, то транзакции Т2 предоставляется доступ к предварительно зафиксированному варианту этого объекта. Такой вариант обычно хранится в каком-то особом месте системы (как правило, в журнале регистрации) и предназначается для восстановления последнего состояния системы.

Если транзакция Т2 пытается выполнить операцию обновления объекта, который в данный момент считывается транзакцией Т1, то транзакции Т2 предоставляется доступ к этому объекту, тогда как транзакции Т1 предоставляется доступ к некоторому варианту этого объекта (который в действительности является предварительным вариантом).

Если транзакция Т2 пытается выполнить операцию обновления объекта, который в данный момент обновляется транзакцией Т1, то транзакция Т2 переходит