Сериализуемые транзакции

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

Сериализуемость может быть достигнута несколькими способами. Один из способов — обработка транзакций с использованием двухфазной блокировки (two-phase locking). При этой стратегии транзакциям позволяется налагать блоки­ровки по мере необходимости, но как только первая блокировка снимается, данная транзакция уже не может наложить никаких других блокировок. Таким образом, транзакции имеют фазу нарастания (growing phase), на которой блокировки на­лагаются, и фазу сжатия (shrinking phase), на которой блокировки снимаются.

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

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

Рассмотрим ввод заказа с помощью представления ЗАКАЗ–ПОКУПАТЕЛЬ, бази­рующегося на таблицах ПОКУПАТЕЛЬ, ПРОДАВЕЦ и ЗАКАЗ. Чтобы гарантировать, что база данных не пострадает от аномалий, вызванных параллельной обработкой, транзакция ввода заказа налагает блокировки на таблицы ПОКУПАТЕЛЬ, ПРОДАВЕЦ и ЗАКАЗ по мере необходимости, производит все необходимые изменения в базе данных, а затем снимает блокировки.

40, БЛОКИРОВКА РЕСУРСОВ: ВЗАИМНАЯ БЛОКИРОВКА.

Взаимная блокировка

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

Рис. 6. Взаимная блокировка

На этом рисунке пользователи А и В оказываются в ситуации, которая носит название взаимной блокировки (deadlock), или «смертельного объятия» (deadly embrace). Каждый из них ожидает освобождения ресурса, заблокированного дру­гим пользователем. Есть два распространенных способа решения этой проблемы: не допускать возникновения взаимных блокировок либо позволять им возникать, а затем распутывать их.

Предотвратить возникновение взаимной блокировки можно несколькими спо­собами. Первый из них – заставлять пользователей блокировать все требуемые ресурсы сразу. Если бы, например, пользователь А на рисунке с самого начала заблокировал и карандаши, и бумагу, взаимная блокировка не возникла бы. Второй способ предотвратить взаимную блокировку – потребовать от всех прикладных программ блокировать ресурсы в одном и том же порядке. Даже если не все при­ложения будут налагать блокировки таким образом, вероятность возникновения взаимной блокировки снизится хотя бы для тех приложений, которые используют данную стратегию. Эту философию можно распространить на организационные стандарты программирования следующим образом: «При обработке строк таб­лиц в связи родитель-потомок всегда блокируй сначала родителя, затем потом­ка». Это, по крайней мере, снизит вероятность взаимной блокировки, а может и вовсе исключить ее.

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

41,БЛОКИРОВКА РЕСУРСОВ: ОПТИМИСТИЧЕСКАЯ И ПЕССИМИСТИЧЕСКАЯ БЛОКИРОВКИ.