Решение задачи перевода денег

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

• Заблокировать таблицу даже для чтения и выполнить две операции модификации, после чего снять блокировку, разрешая другим пользователям работать с таблицей;

• Объявить транзакцию на таблице и, выполнив требуемые действия, завершить транзакцию.

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

Система поддержки транзакций в субд HyTech

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

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

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