Транзакции и сервис транзакций в 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 – сервер.
Механизм надежного завершения транзакции: применение так называемой двухфазной схемы подтверждения завершения транзакции.