15.10. Резюме

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

Наиболее распространенным методом разрешения указанных проблем является ис- пользование механизма блокировки. Существует два основных типа блокировок: раз- деляемая (S-блокировка) и эксклюзивная (Х-блокировка). Если транзакция устанав- ливает S-блокировку для некоторого объекта, то другие транзакции также смогут ус- тановить S-блокировку для этого же объекта, однако установить для него X- блокировку им не удастся. Если одна транзакция устанавливает Х-блокировку для не- которого объекта, то никакая другая транзакция не сможет установить для этого объ- екта никакой другой блокировки. Специальный протокол использования этих блоки- ровок позволяет устранить упомянутую выше проблему утраты результатов обновле- ния и другие возможные проблемы. В соответствии с данным протоколом S- блокировка устанавливается для всех считываемых объектов, а Х-блокировка— для всех обновляемых объектов, причем все установленные блокировки сохраняются до окончания выполнения транзакции. С помощью этого протокола можно обеспечить упорядоченность графика выполнения транзакций.

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

В общем случае нельзя гарантировать безопасность выполнения набора транзакций, если используемый график не полностью упорядочен. Однако в некоторых системах для повышения их производительности и пропускной способности предусмотрена возмож- ность чередующегося выполнения нескольких транзакций с некоторым установленным уровнем изоляции, что на самом деле является не совсем безопасным решением. В этой главе был описан один такой "небезопасный уровень", т.е. уровень стабильности кур- сора (с точки зрения терминологии, принятой в СУБД DB2, хотя в стандарте языка SQL аналогичный уровень называется READ COMMITTED).

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

намерения для "родительского" объекта этого элемента (в случае кортежа — для пе- ременной-отношения, в которой кортеж содержится). На практике блокировки на- мерения обычно устанавливаются так же, как S- и Х-блокировки кортежей, т.е. не- явным образом. Однако рекомендуется предусмотреть оператор типа LOCK для яв- ной установки (в случае необходимости) блокировок более сильных, чем те, кото- рые устанавливаются системой неявно.

Наконец, в этой главе были кратко описаны средства управления параллельно- стью, предусмотренные в языке SQL. В стандарте языка SQL средства явной уста- новки блокировки не предусмотрены вовсе, однако в нем поддерживаются различ- ные уровни изоляции (SERIALIZABLE, REPEATABLE READ, READ COMMITTED, READ UNCOMMITTED), которые в СУБД обычно реализуются средствами неявного автома- тического блокирования.

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

Упражнения

1. Дайте определение понятия упорядочиваемости.

2. Дайте подробное описание:

а) протокола двухфазной блокировки;

б) теоремы двухфазной блокировки.

15.3. Пусть даны транзакции Tl, Т2 и ТЗ, которые выполняют следующие операции:

Т1: добавить 1 к А; Т2: удвоить значение А;

ТЗ: вывести значение А на экран, а затем поместить в А значение 1 (здесь А — некоторый объект базы данных).

а) Допустим, что транзакции Tl, Т2 и ТЗ выполняются параллельно. Перечислите все возможные результаты их выполнения, если начальное значение А равно нулю.

б) Допустим, что транзакции Tl, Т2 и ТЗ имеют показанную ниже внутреннюю структуру.

Tl	T2	ТЗ
Rl: Считать значение A в tl tl := tl + 1 Ul: Поместить в А зна- чение tl	R2: Считать значение A в t2 U2: Поместить в А зна- чение t2	R3: Считать значение А в t3 Вывести значение t3 на экран U3: Поместить в А значе- ние 1

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

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

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

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

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

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

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

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

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

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

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

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

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

15.1. Bayer R., Heller М., Reiser A. 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 предоставляется доступ к некоторому варианту этого объекта (который в действительности яв- ляется предварительным вариантом).

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

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

15.2. Berenson Н. et al. A Critique of ANSI SQL Isolation Levels // Proc. 1995 ACM SIGMOD Int. Conf. on Management of Data. — San Jose, Calif, May, 1995.

В этой статье критически оценивается предпринятая в стандарте SQL попытка оха- рактеризовать уровни изоляции на основе нарушений упорядочиваемости (см. раз- дел 15.9). "[Эти] определения не способны должным образом охарактеризовать не- сколько широко распространенных уровней изоляции, включая стандартные способы реализации блокировок для упомянутых уровней." В частности, в этой статье под- черкивается, что данный стандарт не способен запретить некорректное считывание (которое определяется, как вероятность того, что две транзакции, Т1 и Т2, смогут вы- полнить обновление одной и той же строки до завершения какой-либо из них). Похоже, что это действительно так, поскольку в данном стандарте некорректное считывание не запрещено явным образом. Вот несколько перефразированных ци- тат из этой работы.

• "Выполнение параллельных транзакций на уровне изоляции SERIALIZABLE га- рантированно является упорядоченным." Иначе говоря, если все транзакции выполняются на уровне изоляции SERIALIZABLE, в реализации требуется за- претить операции некорректного считывания, поскольку они будут нарушать упорядоченность графика.

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

• "Изменения, выполненные одной транзакцией, не могут быть восприняты дру- гими транзакциями [за исключением транзакций на уровне READ UNCOMMITTED] до тех пор, пока ее выполнение не будет зафиксировано." Что в данном контек- сте означает слово восприняты! Может ли транзакция обновить часть "неаккуратно считываемых данных" без их "восприятия"?

Замечание. Все эти замечания взяты из работы [4.19],

15.3. Bernstein Р.А., Goodman N. Timestamp-Based Algorithms for Concurrency Control in Distributed Database Systems // Proc. 6th Intern. Conf. on Very Large Data Bases. — Montreal, Canada, October, 1980.

⁷ Иначе говоря, конфликты могут происходить только между операциями обновления и для их устранения используется механизм блокировки. Однако для устранения конфликтов, безуслов- но, могут использоваться и другие методы, например временные отметки [15.3].

В работе рассматриваются некоторые методы управления параллельностью, в основу которых положена не блокировка, а временные отметки. Основная идея заключается в том, что если транзакция А начинает выполняться раньше тран-

закции В, то система ведет себя так, как будто выполнение транзакции А полно- стью завершилось еще до начала выполнения транзакции В (как это имеет место в последовательном графике запуска). Таким образом, для транзакции А будут недоступны любые обновления, выполняемые транзакцией В. Кроме того, она не сможет обновить объект, уже считанный транзакцией В. Подобная схема управ- ления может быть организована следующим образом. Для каждого запроса к ба- зе данных система сравнивает временную отметку транзакции этого запроса с временной отметкой транзакции, выполнившей последнее считывание или об- новление запрашиваемого кортежа. В случае конфликта транзакция запроса мо- жет быть перезапущена с новой временной меткой (так же, как и в случае с оп- тимистическими методами [15.14]).

Как следует из заголовка этой работы, данная методика была изначально создана в контексте распределенной системы (где использование блокировки сопряжено с возникновением нежелательных накладных расходов из-за отправки сообще- ний для проверки и установки блокировок). Однако такая методика почти навер- няка не годится для нераспределенных систем. Кроме того, существует доста- точно скептическое отношение к практичности ее использования даже для рас- пределенных систем. Одной очевидной проблемой является то, что каждый кор- теж должен содержать временную метку последней транзакции, которая считы- вала данные этого кортежа (а также временную метку последней транзакции, ко- торая обновляла данные этого кортежа). В таком случае подразумевается, что каждая операция чтения становится операцией записи! Действительно, в [14.12] утверждается, что такая схема на самом деле является частным случаем схем оп- тимистического метода управления параллельностью [15.14], для которых, в свою очередь, характерны собственные проблемы. 15.4. Blasgen M.W., Gray J.N., Mitoma М., Price T.G. The Convoy Phenomenon // ACM Operating Systems Review. — April, 1979. — 13, N° 2.

Проблема образования верениц возникает при использовании механизма блоки- ровок для интенсивно применяемых элементов данных. Примером может служить установка блокировки перед выполнением операции записи в журнал регистрации в системах с приоритетным планированием.

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

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

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

15.5. Eswaran К.Р., Gray J.N., Lorie R.A., Traiger I.L. The Notions of Consistency and Predicate Locks in a Data Base System // CACM. ■— November, 1976. — 19, № 11.

В этой работе впервые предложено строгое теоретическое описание основ управ- ления параллельностью.

15.6. Franaszek P., Robinson J.T. Limitations on Concurrency in Transaction Processing // ACM TODS. — March, 1985. — 10, № 1.

См. комментарий к [15.14].

15.7. Franaszek P., Robinson J.T., Thomasian A. Concurrency Control for High Contention Environments // Ibid. — 1992. — 17, № 2.

В статье делается заявление, что в будущем системы обработки транзакций, веро- ятно, будут обеспечивать гораздо большую степень параллельности, чем совре- менные системы (по разным причинам). Поэтому в них будут гораздо чаще возни- кать конфликтные ситуации на уровне данных. Затем авторы представляют "несколько концепций управления параллельностью [без использования блокиров- ки] и методов планирования транзакций, которые применимы к средам с большим количеством конфликтных ситуаций". Преимущества такого подхода подтвержда- ются экспериментами с различными имитационными моделями.

15.8. Gray J.N. Experience with the System R Lock Manager. IBM San Jose Research Laboratory internal memo, 1980.

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

• Использование блокировок связано с накладными расходами в размере 10% при работе с интерактивными транзакциями и в размере 1% при работе с пакет- ными транзакциями.

• Желательно поддерживать разные уровни детализация блокировок.

• Приветствуется автоматическая эскалация уровня блокировок.

• Ситуации взаимной блокировки очень редко возникают на практике и никогда не включают более двух транзакций. Почти все ситуации взаимной блокировки (97%) можно устранить с помощью U-блокировок, что и предусмотрено в

СУБД DB2, но не в системе System R. (В определении предполагается, что U- блокировки совместимы с S-блокировками, но не с другими U-блокировками и, конечно, не с Х-блокировками. Более подробные сведения приводятся в [4.20].)

■ Уровень изоляции ПС (повторяемости считывания) более эффективен и безопа- сен, чем уровень СК (стабильности курсора).

15.9. Gray J.N., Lorie R.A., Putzolu G.R. Granularity of Locks in a Large Shared Data Base // Proc. 1st Intern. Conf. on Very Large Data Bases. — Framingham, Mass., September, 1975. В статье впервые описана концепция блокировки намерения. Как объясняется в разделе 15.8, понятие "уровень детализации блокировок" относится к размеру бло- кируемых объектов. Поскольку разные транзакции, очевидно, имеют разные ха- рактеристики и требования, желательно, чтобы в системе существовал целый на- бор различных уровней детализации (что, в принципе, реализовано во многих сис- темах). В этой статье представлена методика воплощения нескольких уровней де- тализации блокировок на основе механизма блокировки намерения.

Поскольку в данной главе было дано весьма упрощенное описание протокола блокировки намерения, ниже он будет рассмотрен несколько подробнее. Во- первых, стоит отметить, что блокируемыми объектами могут быть не только пе- ременные-отношения и кортежи, как предполагалось прежде. Во-вторых, типы блокируемых объектов могут в общем случае не обладать строгой иерархиче- ской структурой. Присутствие индексов или других структур доступа будет лишь означать, что систему объектов следует рассматривать как ориентированный ациклический граф. Например, база данных поставщиков и товаров может со- держать как хранимую переменную-отношение товаров Р, так и индекс, напри- мер ХР, построенный для атрибута #Р этой переменной-отношением. Для выбор- ки кортежей переменной-отношения Р следует открыть всю базу данных, а затем либо перейти непосредственно к этому отношению и выполнить последователь- ный поиск, либо использовать индекс ХР для прямого перехода к искомым кор- тежам переменной-отношения Р. Таким образом, кортежи переменной- отношения Р в этом графе имеют два "родительских" объекта, Р и ХР, для каждо- го из которых "родительским" объектом является база данных. Теперь формулировку этого протокола можно представить в более обобщенной форме.

• При установке Х-блокировки для данного объекта для всех его дочерних объек- тов неявным образом устанавливается Х-блокировка.

• При установке S- или SlX-блокировки для данного объекта для всех его дочер- них объектов неявным образом устанавливается S-блокировка.

• Прежде чем транзакция сможет потребовать установить S- или IS-блокировку для заданного объекта, она должна установить IS-блокировку (или более силь- ную) по крайней мере для одного из его родительских объектов.

• Прежде чем транзакция сможет потребовать установить Х-, IX- или SIX- блокировку для заданного объекта, она должна установить IX-блокировку (или более сильную) для всех родительских объектов этого объекта.

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

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

15.10.Gray J.N., Lorie R.A., Putzolu G.R., Traiger I.L. Granularity of Locks and Degrees of Consistency in a Shared Data Base // Proc. 1FIP TC-2 Working Conf. on Modeling in Data Base Management Systems (ed. G. M. Nijssen). — Amsterdam, Netherlands: North-Holland; New York, N.Y.: Elsevier Science, 1976.

В статье впервые введено понятие уровня изоляции (под названием степень не- противоречивости).

15.11.Harder Т., Rothermel К. Concurrency Control Issues in Nested Transactions // The VLDB Journal. — January, 1993. —2, № 1.

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

15.12.Jordan J.R., Banerjee J., Batman R.B. Precision Locks // Proc. 1981 ACM SIGMOD int. Conf. on Management of Data. — Ann Arbor, Mich., April-May, 1981.

Точная блокировка является схемой блокировки на уровне кортежей, которая га- рантирует блокировку только нужных кортежей (для достижения упорядочиваемо- сти), включая фантомы. На самом деле эта форма блокировки называется блоки- ровкой предикатов [15.5]. Она основана на следующих действиях. Во-первых, на проверке запросов на обновление с целью выяснения, удовлетворяет ли вставляе- мый или удаляемый кортеж предыдущему запросу на выборку в некоторой парал- лельной транзакции. Во-вторых, на проверке запросов на выборку с целью выясне- ния, удовлетворяет ли вставляемый или удаляемый в некоторой параллельной транзакции кортеж данному запросу на выборку. Эта схема не только элегантна, но и, как заявляют ее авторы, обладает более высокой производительностью, чем обычные методы (в которых блокируется чрезмерно много объектов).

15.13. Korth H.F., Speegle G. Formal Aspects of Concurrency Control in Long-Duration Transaction Systems Using the NT/PV Model // ACM TODS. — September, 1994. — 19, № 3.

Как уже отмечалось в литературе (см., например, [14.3], [14.9], [14.15] и [14.16]), упорядочиваемость часто рассматривается как чрезмерно строгое требование, ко- торое накладывается на некоторые виды систем обработки транзакций, особенно в новых прикладных областях, включающих взаимодействие с людьми, а значит, и транзакции большой длительности. В данной статье представлена новая модель обработки транзакций NT/PV (nested transactions with predicates and views), позво- ляющая решить эти проблемы. В статье также показано, что стандартная модель обработки транзакций с упорядочиванием является лишь частным случаем; после дается определение "новых и более полезных классов корректности". Здесь утвер- ждается, что новая модель обеспечивает "необходимую основу для решения про- блем, связанных с долговременными транзакциями".

15.14.Kung H.T., Robinson J.T. On Optimistic Methods for Concurrency Control // ACM TODS, — June, 1981. — 6, № 2.

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

Позднее в [15.6] было показано, что при некоторых разумных предположениях оп- тимистические методы демонстрируют некоторые присущие им преимущества по сравнению с традиционными методами блокировки для некоторого уровня парал- лельности (т.е. некоторого числа одновременно выполняемых транзакций), кото- рый они способны поддерживать. Предполагается, что оптимистические методы могут быть наиболее полезны в системах с большим количеством параллельных процессоров. (В [14.12], наоборот, утверждается, что оптимистические методы в общем случае на самом деле хуже методов блокировки в некоторых "горячих" си- туациях, т.е. в ситуациях, когда объект данных обновляется очень часто и несколь- кими различными транзакциями. Более подробную информацию о методах, эффек- тивных при работе в подобных ситуациях, можно найти в [15.15].) 15.15.0'Neil Р.Е. The Escrow Transactional Method // ACM TODS. — December, 1986. — 11, №4.

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

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

В статье описывается несколько ситуаций, в которых можно использовать метод депонирования. Одним из примеров коммерческого продукта, в котором поддер- живается данный метод, является информационная система IMS Fast Path фирмы IBM. Следует отметить, что этот метод может рассматриваться как особый случай оптимистического управления параллельностью [15.14] (обратите внимание, одна- ко, что именно специфичность, т.е. применение специальных операторов обновле- ния, и является важнейшим условием).

15.16.Papadimitriou С. The Theory of Database Concurrency Control.— Rockville, Md.: Computer Science Press, 1986.

Учебное пособие, в котором особое внимание уделяется формальной теории. 15.17.Salem К., Garcia-Molina G., Shands J. Altruistic Locking // ACM TODS.— March, 1994. — 19, № 1.

В этой статье предлагается расширение протокола двухфазной блокировки, в соответствии с которым транзакция Т1, завершившая работу с заблокирован- ным элементом данных (который не может быть разблокирован из-за ограни- чений протокола двухфазной блокировки), все же "возвращает" этот элемент системе, тем самым позволяя некоторой транзакции 12 установить для него блокировку. В этом случае говорят, что транзакция Т2 "идет вслед за" транзак- цией Tl. Здесь определены протоколы, например сокрытия от транзакции об- новлений, которые выполняются следующими за ней транзакциями. Показано, что альтруистическая блокировка (этот термин происходит от того факта, что "возвращение" данных приносит пользу другим транзакциям, а не транзакции- донору) обеспечивает более высокую степень параллельности, чем обычный протокол двухфазной блокировки, особенно когда некоторые из транзакций продолжаются достаточно долго.

Ответы к некоторым упражнениям

15.3.

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

Исходно : А = О

Т1-Т2-ТЗ Т1-ТЗ-Т2 Т2-Т1-ТЗ

А = 1 А = 2 А = 1

Т2-ТЗ-Т1 ТЗ-Т1-Т2 ТЗ-Т2-Т1

А = 2 А = 4 А = 3

Конечно, не все шесть полученных результатов отличаются один от другого. Фактически в данном примере так получилось потому, что благодаря природе транзакции ТЗ возможные правильные результаты независимы от начального состояния базы данных, б) Существует 90 возможных графиков запуска, отличных один от другого, кото- рые можно представить в приведенном ниже символическом виде. (Здесь Ri, Rj, Rk обозначают операции извлечения Rl, R2, R3, причем необязательно в той же последовательности. Аналогично Up, Uq, Ur обозначают операции обновле- ния Ul, U2, U3, необязательно в той же последовательности.)

Ri-Rj-Rk-Up-Uq-Ur :3*2*1*3*2*1=36 вариантов

Ri-Rj-Up-Rk-Uq-Ur :3*2*2*1*2*1=24 вариантов

Ri-Rj-Up-Uq-Rk-Ur :3*2*2*1*1*1=12 вариантов

Ri-Up-Rj-Rk-Uq-Ur : 3*1*2*1*2*1=12 вариантов

Ri-Up-Rj-Uq-Rk-Ur :3*1*2*1*1*1= 6 вариантов

Всего =90 вариантов

в) Да. Например, график запуска R1-R2-R3-U3-U2-U1 приводит к тому же ре- зультату (единица) для заданного начального значения (нуль), что и два из шести возможных последовательных графиков запуска. (Упражнение. Про- верьте это утверждение.) Однако следует понимать, что "корректность" по- лученного результата является всего лишь счастливой случайностью и след- ствием того, что исходное значение было равно 0, а не какому-то другому числу. В качестве примера обратной ситуации рассмотрите случай, когда ис- ходное значение равно 10. Будет ли показанный выше график запуска давать один из действительно корректных результатов? (Какими в этом случае бу- дут действительно корректные результаты?) Если нет, то график запуска R1-R2-R3-U3-U2-U1 не допускает упорядочения.

г) Да. Например, график запуска R1-R3-U1-U3-R2-U2 является упорядоченным (он эквивалентен последовательном} графику запуска Т1-Т2-ТЗ), но не может быть получен, если выполнение транзакций Tl, Т2 и ТЗ подчиняется двухфазному протоколу блокировки. В этом случае для выполнения операции R3 потребуется установить S-блокировку для элемента А с согласия транзакции ТЗ. Тогда опе- рация U1 в транзакции Т1 не будет выполняться до тех пор, пока не будет снята блокировка, а это не произойдет до завершения выполнения транзакции ТЗ (действительно, при достижении операции U3 транзакции ТЗ и Tl попадут в си- туацию взаимной блокировки).

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

корректному финальному состоянию или, по крайней мере, могут привести к нему для некоторого начального состояния, множество всех допускающих упорядочи- вание графиков запуска (SERIALIZABLE), а также множество всех графиков запуска (PRODUCIBLE), которые приводят к корректному результату при использовании двухфазного протокола блокировки. Тогда в общем случае будет верно следующее утверждение (здесь знак "<" обозначает "подмножество").

PRODUCIBLE < SERIALIZABLE < CORRECT < ALL

4. В момент tn ни одна из транзакций не выполнит никакой полезной работы! Дело в том, что имеет место ситуация взаимной блокировки, включающая транзакции Т2, ТЗ, Т9 и Т8. Кроме того, транзакция Т4 находится в состоянии ожидания (ожидает) завершения выполнения транзакции Т9, транзакция Т12 ожидает завершения вы- полнения транзакции Т4, а транзакции Т10 и Т11 ожидают завершения выполнения транзакции Т12. Эту ситуацию можно представить с помощью приведенного на рис. 15.14 графа ожидания, узлы которого представляют собой транзакции, а на- правленные от узла Ti к узлу Tj ребра указывают на то, что транзакция Ti нахо- дится в состоянии ожидания завершения выполнения транзакции Т]. Возле стрелок размещены названия объектов базы данных с указанием в скобках уровня блоки- ровки, в котором они находятся в состоянии ожидания.

5. Для задач, приведенных на рис. 15.1-15.3, уровень изоляции стабильности курсора обладает тем же эффектом, что и уровень повторяемости считывания (обратите внимание, однако, что для СУБД DB2 это утверждение не применимо к уровню стабильности курсора из-за того, что в этой СУБД вместо S-блокировок использу- ются U-блокировки [4.20]). Что касается проблемы несогласованной обработки данных (см. рис. 15.4), то уровень изоляции стабильности курсора не позволяет разрешить эту проблему. Дело в том, что транзакция А должна выполняться на уровне повторяемости считывания для того, чтобы сохранить все свои блокировки до завершения выполнения транзакции, иначе будет получен неверный результат. (Конечно, если система поддерживает такой режим, то в качестве альтернативного варианта можно было бы с помощью транзакции А полностью заблокировать всю переменную-отношение счетов, установив некоторую явно заданную блокировку. Это решение можно было бы использовать как для уровня стабильности курсора, так и для уровня повторяемости чтения.)

6. См. раздел 15.8. Обратите внимание на то, что формальные определения даются с помощью матрицы совместимости типов блокировок (см. рис. 15.11).

15.9. В этой главе были рассмотрены три проблемы параллельности, а именно: пробле- мы потери результатов обновления, зависимости от незафиксированных резуль- татов и несогласованной обработки данных.

• Потеря результатов обновления. Согласно стандарту языка SQL требуется, что- бы при любых обстоятельствах проблема потери результатов обновления нико- гда не возникала.

• Зависимость от незафиксированных результатов. Это всего лишь иное назва- ние проблемы некорректного чтения.

• Несогласованная обработка данных. Этим термином обозначаются как пробле- ма неповторяемости чтения, так и проблема чтения фантомов.

Т10

Т11

А ( X )

С ( X )

D ( X

g { s

Н ( X )

g ( s

_V

Т2

Т8

е ( s )

F ( X )

Рис. 15.14. Граф ожидания для упр. 15.4

15.10.Приведенное ниже краткое описание взято из [20.15]. Прежде всего в системе должны выполняться следующие условия.

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

2. Необходимо поддерживать список идентификаторов транзакций для всех за- фиксированных транзакций (список фиксации).

В момент начала выполнения транзакции система предоставляет ей закрытую ко- пию списка фиксации. Операции чтения объекта направляются к последней вер- сии объекта, полученной с помощью транзакции из этого закрытого списка. А операции обновления выполняются с фактическим текущим состоянием объекта данных (вот почему все еще необходимо выполнять проверку конфликта "обновление/обновление"). После фиксации транзакции система обновляет спи- сок фиксации и стеки версий объектов данных.