Транзакции и сервис транзакций в CORBA.

Можно без преувеличения сказать, что построение надежной системы без использования транзакций невозможно.

Транзакции в распределенных системах носят существенно более общий характер, чем в реляционных базах данных. Задача объектных транзакций – корректно изменять состояние объектов, из которых строится система.

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

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

Целостность (Consistency). Это свойство транзакций подразумевает понимание системы, а не просто особенностей ее физической реализации. «Целостность» означает, что транзакция переводит систему из одного «правильного» состояния (с точки зрения функциональности системы) в другое. Например, в бухгалтерской системе деньги со счетов в активной части должны попасть на соответствующий счет в пассивной, и такой перевод средств не может быть разделен на две или более транзакций.

Изоляция (Isolation). Уровни изоляции транзакции определяются в терминах возможности возникновения конфликтов между транзакциями разных пользователей или одного и того же пользователя. Можно классифицировать возникающие проблемы по трех категориям.

Так называемое «грязное чтение» (Dirty Read). Транзакции не изолированы друг от друга, и одна транзакция может видеть любые промежуточные результаты другой. Строго говоря, такой уровень изоляции является нарушением принципа изоляции.

Так называемое «неповторяющееся чтение»(Nonrepeatable Read). Проблема состоит в том, что два вызова в одной и той же транзакции одинакового оператора SELECT возвращают разные ответы. Происходит это из-за того, что другая транзакция в промежутке между вызовами SELECT успела выполнить оператор UPDATE и завершиться.

Так называемые «фантомные объекты» (Phantom). Проблема похожа на предыдущую, но проблема возникает при выполнении второй транзакцией команд INSERT или DELETE.

В CORBA вводятся пять уровней изоляции транзакций:

TRANSACTION_NONE – транзакции не поддерживаются.

TRANSACTION_READ_UNCOMMITTED – возможно возникновение всех трех проблем.

TRANSACTION_READ_COMMITTED – невозможно возникновение «грязного чтения», но возможно возникновение двух других.

TRANSACTION_REPEATABLE_READ – возможно только появление проблемы «фантомов».

TRANSACTION_SERIALIZABLE – невозможно возникновение ни одной из проблем.

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

Сохраняемость (Durability). Этот термин означает, что результаты завершенной транзакции должны «навсегда» менять состояние системы.

Широко известны две реализации объектного сервиса транзакций: OTS (Object Trasaction Service) – сервис транзакций в J2EE и MTS (Microsoft Transaction Service) – в Windows. Важнейшим отличием модели MTS от модели OTS является то, что MTS поддерживает участие в транзакциях только объектов, которые не имеют состояния (условно говоря, для каждой транзакции заново создаются новые серверные объекты, которые уничтожаются при ее завершении). OTS позволяет участвовать в транзакциях объектам с состоянием (объекты до начала транзакции имели состояние, оставшееся от предыдущей транзакции).

При практической реализации сервера транзакций в распределенной системе следует учесть следующие требования – характеристики:

Наличие дополнительного участника – монитора транзакций, так как подсистемы распределенной системы работают независимо друг от друга.

Наличие уникального идентификатора транзакции и поддержание контекста.

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

При неявной передаче контекста требуется обеспечить доступ клиентских приложений к контексту.

Универсадьный механизм регистрации всех объектов – участников транзакции.

Обеспечение стыковки с существующими программными средствами, традиционно поддерживающими некотрый механизм транзакций, например, SQL – сервер.

Механизм надежного завершения транзакции: применение так называемой двухфазной схемы подтверждения завершения транзакции.