Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

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

Читайте также:
  1. World Wide Web — главный информационный сервис.
  2. Автономные транзакции
  3. Автосервис.
  4. Блокировки транзакций
  5. В сфере сервиса и туризма наиболее распространены следующие формы оплаты труда и стимулирования работников.
  6. Журнал транзакций. проблемы обработки параллельных транзакций
  7. Значение и сущность логистического сервиса.
  8. И СЕРВИСНЫЕ УСЛУГИ ДЛЯ ПОКУПАТЕЛЕЙ
  9. Информационные технологии используемые в автосервисных предприятиях
  10. Календарь Табель Разное Сервис
  11. Категории рыночного сервиса
  12. Комплекс сервисного обслуживания

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

Основные задачи объектных адаптеров – 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 – сервер.

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

 

<== предыдущая лекция | следующая лекция ==>
| Транзакции и сервис транзакций в CORBA

Дата добавления: 2014-01-04; Просмотров: 118; Нарушение авторских прав?;


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



ПОИСК ПО САЙТУ:


Читайте также:



studopedia.su - Студопедия (2013 - 2017) год. Не является автором материалов, а предоставляет студентам возможность бесплатного обучения и использования! Последнее добавление ip: 54.224.102.26
Генерация страницы за: 0.008 сек.