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

Объектные адаптеры.

Основные задачи объектных адаптеров – OA:

Создание CORBA – объектов, и, следовательно, объектных ссылок уровня ORB IOR (Interoperable Object Reference). Создание объекта не обязательно связано с созданием серванта (это может быть выполнено и позднее). С каждым создаваемым объектом сопоставляются Object ID – уникальный ключ внутри фабрики объектов и Object Key - Object ID и идентификатор фабрики объектов.

Создание сервантов по указанию программиста, например в момент поступления запроса от клиентского приложения.

Управление созданными сервантами и направление к ним запросов клиентов.

Уничтожение сервантов. Это нетривиальная задача, так как следует убедиться в том, что сервант никому больше не нужен. В условиях многопоточных приложений это непросто. Обычно OA ведет счетчик объектных ссылок на каждый сервант.

Умение работать с OA нужно только «чистому» CORBA – программисту. Тем не менее, попытаемся кратко разобраться с некоторыми характеристиками работы объектных адаптеров.

Политика нитей. Определяется, каким образом обрабатываются запросы. Варианты ответов: один за другим, запросы клиентов к серванту могут поступать в конкурентном режиме из различных потоков.

Политика продолжительности жизни. Создаваемые серванты могут быть временными (прекращать существование по окончании работы серверного приложения, создавшего его) или долгоживущими.

Политика уникальности объектного идентификатора. Можно разрешить (или запретить) режим работы, при котором на один сервант может ссылаться несколько объектных ссылок. Это удобно применять в том случае, если есть много долгоживущих объектов, состояние которых хранится в БД (для каждого объекта в отдельной записи), тогда удобно применять в качестве ключа значение Object ID для серванта, который не имеет состояния, но в случае необходимости извлекает всю необходимую информацию из БД.

Политика назначения идентификатора определяет, кто назначает ID создаваемому объекту, сама фабрика объектов или программист.

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

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

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

Атомарность (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 – сервер.

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