Транзакции

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

1. Транзакции должны быть атомарными. Либо вносятся все изменения, необходимые для

совершения транзакции, либо никакие.

2. Во время обработки транзакции одного клиента данные должны выглядеть так, как они

выглядели в начале незавершенных транзакций всех остальных клиентов. До момента своего завершения транзакция остается невидимой для других клиентов; все выглядит так, словно транзакция и не начиналась.

3. Если сразу несколько клиентов в своих транзакциях пытаются изменить один объект,

допускается успешное завершение не более одной транзакции.

Последнее правило гарантирует, что каждый объект обновляется не более чем одним клиентом.

Существуют две стратегии его реализации:

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

собирается изменить. Если транзакции не удается установить необходимые блокировки, она

вообще не начинается.

2. Запрос на блокировку выдается не вначале, а во время транзакции по мере выполнения

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

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

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