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

2. Запрос на блокировку выдается не вначале, а во время транзакции по мере выполнения обновлений. Если необходимый объект уже заблокирован другим клиентом, то транзакция либо ожидает его освобождения, либо завершается неудачей.

Вторая стратегия может привести к взаимной блокировке (deadlock): транзакция A блокирует объект X и ожидает возможности блокировки объекта Y, тогда как транзакция B блокирует объект Y и ожидает возможности блокировки объекта X.

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

Отмена

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

В некоторых языках (таких как Lisp) можно буквально делать снимки памяти в различные моменты времени. При наличии такого снимка вернуться к прежнему состоянию приложения очень просто. Увы. В С++ таких изящных возможностей не предусмотрено; зато наши программы не запрашивают 3 Гб памяти и успевают завершить работу еще до обеда. Так что это замечание стоит воспринимать не как критику С++, а как констатацию факта: проблема есть, и ее необходимо решать.

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

Хватит?

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

Образы и указатели

Разве можно начать новую главу и не ввести новую разновидность указателей? Состояние объекта можно восстановить двумя способами: сохранить его образ (image) до и после операции или же хранить информацию, достаточную для выполнения операций в обратном направлении. Вариант достаточно прост и универсален, а попытки возврата через выполнение операций в обратном направлении привязаны к конкретному объекту и приложению, поэтому я предпочитаю хранить несколько копий одного объекта. Ключевая концепция, обеспечивающая реализацию этой методики на С++ - указатель образов (image pointer). Такие указатели незаметно для клиента содержат несколько

копий указываемого объекта. Существует множество всевозможных комбинаций и вариаций, так что выбор зависит главным образом от вашего настроения.

Простой указатель образов

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

template <c1ass Type> class ImagePtr { private:

Type* current; Текущий образ, предоставляемый компоненту Type* undo; Предыдущий образ

public:

ImagePtr() : undo(NULL), current(new Type) {} ImagePtr(const ImagePtr<Type>& ip)

: current(new Type(*(ip.current))), undo(NULL) {} ~ImagePtr() { delete current; delete undo; } ImagePtr<Type>& operator=(const ImagePtr<Type>& ip)

if (this != &ip) { delete current;

current = new Type(*(ip.current));

return *this;

void Snapshot()

delete undo; На случай, если был старый образ

undo = current;

current = new Type(*undo);

void Commit()

delete undo; undo = NULL;

void Ro11back()

if (undo != NULL) { delete current; current = undo; undo = NULL;

Type* operator->() const { return current; }

Указатель всегда возвращает текущий образ как значение оператора ->, однако за кулисами он прячет предыдущую версию указываемого объекта. Функция Shapshot() создает образ с помощью конструктора копий указываемого объекта. Если клиент передумает и захочет отказаться от изменений, он вызывает функцию Ro11back(); если изменения его устраивают, он вызывает функцию Commit().

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

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

Стеки образов

Для многоуровневой отмены вам может понадобиться стек предыдущих образов. Один из вариантов реализации - хранить стек в каждом указателе образов. В следующем фрагменте предполагается, что у вас имеется параметризованный класс Stack с функциями Empty(), Push(), Pop() и DeleteAll (). Функция Pop() возвращает верхний элемент стека или NULL, если стек пуст. Функция De1eteAl1() опустошает стек и уничтожает все объекты по мере их извлечения. Каждый указатель хранит стек предыдущих образов. Если стек пуст, значит, образы не создавались. Если стек не пуст, в его нижней части находится исходный объект. Функция Ro11back() находит и восстанавливает этот объект. Конструктор копий и оператор = работают так же, как и в описанном выше простейшем указателе образов.

template <c1ass Type> class ImageStackPtr { private:

Type* current; Текущий образ, предоставляемый клиенту Stack<Type> history; Предыдущие образы public:

ImageStackPtr() : current(new Type) {} ImageStackPtr(const ImageStackPtr<Type>& ip)

: current(new Type(*(ip.current))) {} ~ImageStackPtr() { delete current; }

ImageStackPtr<Type>& operator=(const ImageStackPtr<Type>& ip)

if (this != &ip) {

history.DeleteAl delete current;

current = new Type(*(ip.current));

return *this;

void PushImage()

history.Push(current); current = new Type(*current);

void Commit() { history.De1eteAl1(); }

void PopImage() Вернуться на один уровень

if (!history.Empty()) { delete current; current = history.PopO;