|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #02/97
|
|
Многие идеи относительно обработки транзакций, возникшие еще в начале 80-х годов, в особенности представления о более развитых моделях, чем простые "плоские" транзакции, только сейчас начинают находить применение в коммерческих системах. Архитектура ваших приложений, как находящихся в стадии разработки, так и планируемых на будущее, будет существенно зависеть от используемых моделей обработки транзакций. Многозвенные (chained) и вложенные (nested) транзакции, например, позволят создавать распределенные приложения существенно иной структуры и, можно надеяться, значительно более эффективные, чем при наличии лишь рудиментарных моделей. Материал этой главы (в которой вопросы информационного управления рассматриваются под углом зрения структуры прикладных систем) представляет исключительную важность.
На протяжении всей этой книги мы обсуждали концепции обработки транзакций (TP - transaction processing) и связанные с этим тенденции. Мы рассмотрели роль обработки транзакций в управлении распределенными базами данных и информационными системами, а также требования к ТР в объектно-ориентированных базах данных.
В этой главе мы обсудим подробнее тенденции и перспективы обработки транзакций в применении к системам информационного управления в целом. Мы рассмотрим, в частности, следующие вопросы:
Мы можем рассматривать обработку транзакций в самом общем виде, включая множество парадигм - от пакетной и простой терминально-интерактивной обработки (на самом деле концептуальными источниками компьютерной обработки транзакций можно считать шумерские глиняные таблички с записями торговых операций, сделанными за многие тысячелетия до зарождения идеи вычислительной машины)1). Более конкретно, дисциплина ТР включает в себя различные функции для поддержки компьютерных приложений, основанных на коммуникациях. В самом общем смысле системы обработки транзакций могут охватывать все, что может присутствовать в компьютерной системе, - базы данных, репозитории, а также сети и операционные системы2).
Мы сосредоточим свое внимание на базовых сервисах, присущих разным поколениям систем обработки транзакций, подобно тому, как выделяем поколения языков программирования (говоря об языках 3GL, 4GL, 5GL) или поколения баз данных (например, в гл. 1 мы обсуждали "Манифест баз данных третьего поколения", а в гл. 23 рассмотрим системы баз данных четвертого поколения). В области обработки транзакций имеет место следующая классификация (рис. 20-1)3).
Рисунок 20-1.
Поколения систем обработки транзакций.
Хотя понятие "обработка транзакций" применимо практически к любой компьютерной среде, в особенности в мире бизнеса, однако традиционно использование мониторов обработки транзакций ограничивалось окружениями крупномасштабных центров обработки данных, функционирующих на базе мэйнфреймов, в таких прикладных областях, как резервирование авиабилетов или международные банковские операции4). За последние годы, отчасти за счет того, что корпоративные информационные системы все более приобретают черты распределенности и неоднородности, мониторы обработки транзакций стали применяться и во многих других вертикальных приложениях (здравоохранение, страхование, торговля). По оценкам Gartner Group, к 1995 г. в 50% вновь создаваемых приложениях на основе реляционных СУБД будут применяться средства обработки транзакций5).
Обратимся теперь к фундаментальным принципам и основным моделям транзакций, которые определяют пути применения ТР в информационных системах.
Ко всем типам транзакций предъявляется набор требований, известный под названием ACID (atomocity, consistency, isolation, durability). Смысл этих требований заключается в следующем6).
Существуют многочисленные модели транзакций, поддерживающих эти принципы. Они варьируются от простейших, таких как "плоские" транзакции, до более изощренных, таких как вложенные или многозвенные. Рассмотрим эти модели более подробно, поскольку именно сложные модели в значительной мере определяют особенности обработки транзакций в коммерческих информационных системах будущего.
Модели плоских транзакций соответствует один управляющий слой, которому подчинено произвольное число элементарных действий. В современных информационных системах - это, как правило, единственная поддерживаемая на прикладном уровне модель транзакций, хотя внутренние компоненты системы (например, SQL) могут включать более изощренные средства обработки транзакций; однако они не доступны на уровне прикладного программирования. В разд 20.3.4 мы рассмотрим псевдовложение SQL7).
Плоские транзакции - это основные строительные блоки для реализации принципа атомарности; иначе говоря, выделение некоторой последовательности действий в виде плоской транзакции обеспечивает принцип "все или ничего".
Во многих прикладных окружениях, в особенности с централизованными обработкой и управлением ресурсами (например, базами данных и файлами), механизм плоских транзакций на протяжении многих лет предоставлял вполне удовлетворительные возможности как для создания, так и для выполнения приложений; простые преобразования состояний системы вполне укладывались в рамки атомарных единиц работы8).
По мере того как данные и вычисления становятся все более распределенными, атомарность плоских транзакций становится значительным неудобством. Рассмотрим пример на рис. 20-2. Согласно правилам обработки плоских транзакций, либо должны успешно завершиться все компоненты глобальной транзакции, либо не должна завершиться ни одна из них. Например, если неудачей завершилось только изменение одной удаленной базы данных под управлением некоторого менеджера ресурсов, то и все остальные компоненты должны быть возвращены в состояние, предшествовавшее началу транзакции. Учитывая количество информации, обрабатываемой в крупной или даже средней организации со множеством серверов LAN на ПК и, возможно, с мобильными базами данных (см. разд 22.2 в гл. 22, где обсуждается обработка транзакций в среде мобильных вычислений), можно предположить, что вероятность отказа хотя бы одного узла весьма высока. Если применяется модель плоских транзакций, то придется заново выполнять все составные части транзакции, что существенно повышает требования к вычислительным ресурсам и отнимает значительную долю пропускной способности системы.
Рисунок 20-2.
Выполнение плоской транзакции в среде крупной организации.
Очевидно, что в наш век сильно распределенных вычислений необходимо каким-то образом проводить декомпозицию плоских транзакций. Модификация модели плоских транзакций, сохраняющая свойство атомарности, но снижающая потребность в повторном выполнении действий (т. е. в "переработках"), включает понятие контрольных точек, которое мы обсудим в следующем разделе.
Контрольные точки устанавливаются в прикладной программе для того, чтобы отметить моменты, начиная с которых можно продолжить вычисления в случае возникновения проблем. В идеале контрольные точки должны соответствовать частично согласованным состояниям (например, после построения вспомогательной таблицы в программе, которая затем будет использоваться для вычислений с участием еще какой-либо таблицы).
По достижении очередной контрольной точки в транзакции создается новое атомарное действие, которое запускается на выполнение. Только последнее атомарное действие всей последовательности может выполнить фиксацию (COMMIT WORK) транзакции; оператор COMMIT WORK передается всем предыдущим атомарным действиям, пока все они не будут зафиксированы9). В отличие от модели многозвенных транзакций, которые мы рассмотрим в следующем разделе, контрольная точка не приводит к необратимой фиксации, выполненной до этого момента работы.
Прерывания (ROLL BACK), или откаты, транзакции могут инициироваться из любого атомарного действия, а не только из последнего; хотя в любой заданный момент времени прерывание может инициировать только действие, запущенное последним. (Это значит, что если для какого-то атомарного действия была достигнута контрольная точка, то для этого действия уже не может быть в дальнейшем принято решение об откате.) Откат может быть произведен до любой из предыдущих контрольных точек, поэтому менеджер обработки транзакций должен воспринимать параметр, указывающий, до какой именно контрольной точки нужно произвести откат (в идеале логика приложения должна предусматривать определение контрольной точки, до которой в случае неудачи следует откатить выполнение)10).
Проводились исследовательские работы по изучению применимости так называемых устойчивых (persistent) контрольных точек, которые фиксируются в дисковой или другой долговременной памяти, для того чтобы результаты выполнения были доступны после системных крахов. Однако Грей и Реутер отмечают, что "здесь не видно пока никакого решения, которое можно было бы принять безоговорочно"11). Это вряд ли следует считать большой проблемой, поскольку две новые модели транзакций - вложенные и многозвенные транзакции - предоставляют схожие возможности при том, что формальные определения этих парадигм значительно лучше проработаны и общеприняты. Рассмотрим вначале многозвенные транзакции.
Модель многозвенных транзакций (рис. 20-3) концептуально подобна модели контрольных точек, но она предполагает фиксацию части работы, сделанной до некоторого момента; возможность отката зафиксированных действий исключается12).
Рисунок 20-3.
Концептуальное представление многозвенных транзакций.
Приложение тем не менее остается в состоянии транзакции; т. е. при этом не происходит инициации очередной транзакции, ее завершения, инициации следующей и ее завершения и т. д. В рамках многозвенной транзакции сохраняются все необходимые элементы контекста выполнения (курсоры баз данных, открытые файлы и т. д.), хотя ресурсы, ставшие ненужными, можно освобождать13).
Модель многозвенных транзакций включает оператор CHAIN WORK - неделимую комбинацию операторов COMMIT WORK и BEGIN WORK, - которая неравноценна последовательному выполнению операторов COMMIT WORK и BEGIN WORK по отдельности. При выполнении этих операторов по отдельности контекст пропадает; некоторая другая транзакция может "вклиниться" и изменить значения в базе данных, которые нужны для выполнения следующего "звена" многозвенной транзакции, прежде чем это звено начнет выполняться14). Таким образом, многозвенные транзакции концептуально эквивалентны транзакциям с контрольными точками с той разницей, что откат может производиться только до последней зафиксированной точки, а не до любой предыдущей контрольной точки15).
Обе модели транзакций - многозвенные и с контрольными точками - позволяют описывать последовательности действий; различия касаются лишь возможностей отката и устойчивости выполненных до заданной точки действий. Последняя модель, которую мы обсудим, - это модель, которая позволяет описывать не последовательности, а иерархии субтранзакций.
Модель вложенных транзакций включает понятие головной транзакции, которая управляет выполнением всей иерархии. В рамках иерархии могут присутствовать транзакции разных уровней вложенности (рис. 20-4). Концевые узлы иерархии представляют собой плоские транзакции. Отдельные ветви иерархии могут иметь разную длину, т. е. концевые транзакции могут находиться на разном "расстоянии" от головной транзакции (корня дерева транзакций)16).
Рисунок 20-4.
Структура вложенных транзакций.
Правила и модели вложенных транзакций были впервые разработаны Эллиотом Моссом в 1981 г. В модели Мосса реальные действия могли производиться только концевыми субтранзакциями, но Грей и Реутер отмечают, что это правило ограничивает функции вложения транзакций и что его отмена дает дополнительные возможности распараллеливания действий над разделяемыми объектами при введении абстракции многоуровневых объектов17).
Мосс сформулировал три правила для управления вложенными транзакциями18).
Из свойств ACID для субтранзакций выполняются свойства атомарности, согласованности и изолированности. Но поскольку COMMIT WORK для субтранзакции на самом деле не означает ее фиксации до фиксации всей транзакции, то свойство долговечности не выполняется, поэтому субтранзакции не эквивалентны плоским транзакциям19).
Как и другие модели, вложенные транзакции имеют вариации, в том числе модель многоуровневых (multilevel) транзакций, где субтранзакция ST1 "предварительно фиксирует" свои результаты. При этом для нее предусмотрена компенсирующая субтранзакция, которая может отменить выполненные ST1 действия, если происходит прерывание всей транзакции в целом. Компенсирующие транзакции позволяют отменять результаты почти в реальном времени; в их отсутствие приходится применять сценарии восстановления с анализом времени произведенных изменений, для чего используются дорогостоящие оперативные ресурсы, обеспечивающие возврат базы данных в согласованное состояние (например, с применением журналов или путем "сопоставления фрагментов" головоломки-мозаики, для того чтобы определить, каким должно быть согласованное состояние базы данных)20).
Хотя можно представить себе приложения и системы, в которых многозвенные и вложенные транзакции были бы полезны, однако лишь в начале 90-х годов в коммерческих приложениях на смену плоским транзакциям начали приходить другие модели (в разд. 20.4 мы обсудим монитор обработки транзакций Encina). Интересно, впрочем, отметить, что при изучении транзакций SQL можно обнаружить некоторые признаки "псевдовложенности", по крайней мере в способах обработки операторов (это в настоящее время недоступно разработчикам приложений; однако принятый в настоящее время стандарт SQL3 содержит контрольные точки и, вероятно, в него войдут операторы управления многозвенными транзакциями).
На рис. 20-5 показано выполнение транзакции SQL. Каждый оператор внутри транзакции, которая представляет собой, например, последовательность операторов UPDATE и DELETE, может завершиться успешно или неуспешно. Даже если один или несколько операторов завершаются неудачей, транзакция в целом может продолжаться, если в ее логике для этих случаев явно не предусмотрено прерывание с откатом в начальное состояние. Все успешно завершившиеся до прерывания операторы (которые в этой модели можно представлять как субтранзакции) будут отменены, если происходит откат всей транзакции.
Рисунок 20-5.
SQL как модель псевдовложенных транзакций.
Разработчикам приложений приходилось как-то компенсировать недоступность имеющихся в SQL свойств псевдовложенности, применяя различные ухищрения для построения архитектур транзакций, более соответствующих их потребностям, чем простейшие плоские транзакции. Когда на рынке утвердится стандарт SQL3, что произойдет в середине 90-х, и начнут появляться совместимые с ним продукты (вспомним наши рассуждения в гл. 12 о том, что многие черты появляются в коммерческих продуктах еще до включения их в официальные стандарты), разработчики приложений на основе SQL СУБД смогут непосредственно пользоваться преимуществами новых моделей транзакций.
Монитор обработки транзакций Encina корпорации Transarc можно рассматривать как коммерческий продукт второго поколения, однако более развитый, отражающий новейшие достижения в этой области21). Encina включает модель вложенных транзакций и расширяет возможности cреды DCE (Distributed Computing Environment), предложенной организакцией OSF (Open Software Foundation).
Прообразом Encina был прототип системы обработки транзакций Camelot, разработанный в университете Карнеги-Меллон в Питтсбурге. Технология, лежащая в основе Camelot, и применяемый в этой системе язык программирования Avalon описаны в работе Camelot and Avalon: A Distributed Transaction Processing Facility23). Camelot считается "первой реализацией вложенных транзакций в системе обработки транзакций"24) (в отличие от псевдовложенности, которую мы обсуждали в предыдущем разделе, или от внутрисистемной вложенности, недоступной для разработчиков приложений).
Архитектура, которая отражена на рис. 20-6, соответствует степени распределенности, характерной для разработываемых или проектируемых в настоящее время информационных систем. Использование серверов приложений здесь соответствует философии (обсуждавшейся в гл. 2) выделения процедур обработки данных, в отличие от философии выделения самих данных. Хотя пользователи, имеющие достаточные полномочия, могут непосредственно осуществлять доступ к удаленным данным, но в данном случае цель состоит в том, чтобы полностью передать управление данными серверам приложений25).
Рисунок 20-6.
Открытая прикладная среда распределенной обработки транзакций22).
На рис. 20-7 изображен типичный многоуровневый подход к распределенной обработке транзакций, применяемый, в частности, в DCE. Монитор Encina использует предоставляемые DCE абстрактные уровни управления ресурсами и коммуникационных менеджеров и сам обеспечивает прямое подключение к ресурсам и коммуникационным менеджерам, не подчиненным DCE. Модульность и многоуровневость - черты, характерные для современных открытых систем и корпоративных вычислительных архитектур26), - находят отражение и в обработке транзакций. Можно с уверенностью предположить, что концепции открытых систем в дальнейшем будут еще более активно применяться в сфере обработки транзакций.
Рисунок 20-7.
Многоуровневая архитектура обработки транзакций в Encina28).
Одна из задач, решаемых монитором Encina, - это поддержка свойств ACID в среде баз данных клиент-сервер при условии, что клиенты и серверы независимо хранят записи о состоянии транзакций27).
В Encina код, обеспечивающий соблюдение свойств ACID, заключен в менеджерах ресурсов (см. рис. 20-7); приложения и другие программы верхнего уровня выдают запросы на фиксацию или прерывание транзакций, которые менеджеры транзакций реализуют на соответствующих ресурсах нижнего уровня29).
Encina включает язык разработки приложений Transactional C, содержащий набор макросов и библиотек для определения транзакций и управления ими. Ключевое слово TRANSACTION служит для определения транзакций верхнего уровня или вложенных. Функции, задаваемые при помощи ключевых слов ONABORT и ONCOMMIT, описывают действия, выполнямые при откате или, соответственно, фиксации транзакции любого уровня. Программа может вызвать ENCINA_ABORT_ALL, чтобы вызвать прерывание всей транзакции30).
Интересно было бы понаблюдать, как пойдет развитие не только конкретного продукта Encina, но и всей области "открытой обработки транзакций" в целом. Тенденции усиления распределенности и неоднородности, о которых говорилось в гл. 1 и которые направляют развитие технологий баз данных и информационного управления, требуют определенной степени открытости всех компонентов информационных систем (в том числе сервисов операционных систем, безопасности, баз данных и репозиториев, мониторов транзакций). Хотя старые "закрытые" продукты и аппаратные платформы, поддерживаемые ими, просуществуют еще довольно долго, но тенденции, которые иллюстрирует рис. 20-8, неизбежно будут оказывать все более значительное влияние на развитие систем обработки транзакций.
Рисунок 20-8.
Факторы, влияющие на развитие коммерческих мониторов обработки транзакций.
Еще один определяющий фактор развития коммерческих систем обработки транзакций - это стандартизация. Международный комитет по стандартам (ISO) выработал состоящий из двух частей протокол для поддержки медоперабельности систем обработки транзакций. Две составные части этого стандарта31):
Стандарты OSI определяют форматы и протоколы, но не прикладные программные интерфейсы для стандартного протокола двухфазовой обработки транзакций (2PC), спроектированного как надстройка над стеком коммуникационных протоколов OSI.
Стандарт API разработан комитетом X/Open и получил название X/Open Distributed Transaction Processing (DTP) API. X/Open DTP позволяет менеджерам транзакций использовать комбинацию закрытых и OSI-TP-протоколов для внутренних и межоперабельных окружений соответственно. X/Open DTP - стандарт, находящийся в стадии начального развития и имеющий определенные противоречия. В частности, не очень хорошо согласуются две его цели: (1) определение среды монитора TP как стандартизированного окружения и (2) поддержка удаленных вызовов процедур транзакций (TRPC - Transactional Remote Procedure Calls) наряду с "равноправными" (peer-to-peer) моделями коммуникаций (по крайней мере в настоящее время модель X/Open DTP содержит оба подхода)32).
X/Open DTP поддерживает не только плоские транзакции, но также многозвенные и вложенные (в последней из этих моделей при прерывании одной из ветвей происходит прерывание всей транзакции в целом, в отличие от рассмотренной в разд. 20.3.4 более устойчивой модели)33).
В стандартизированной распределенной среде TP для описания взаимодействий между компонентами применяется комбинация стандартных протоколов. Некоторые из них, например ROSE (Remote Operations Service), относятся к общему стеку протоколов OSI; другие являются специфическими для окружения X/Open DTP или OSI-TP. На рис. 20-9 показаны интерфейсы компонентов в стандартизированной распределенной среде TP и соответствующие протоколы и API.
Рисунок 20-9.
Стандартизированная среда обработки транзакций34).
С появлением множества стандартизированных систем обработки транзакций нового поколения полезным представляется проведение их классификации с точки зрения спектра предоставляемых ими функций. Подобную классификацию, включающую пять измерений, предложили Абрахам Лефф и Калтон Пу из Колумбийского университета35):
M - множество машин;
P - множество процессов;
H - степень неоднородности машин и программного обеспечения;
D - множество логических данных;
S - множество узлов.
Эта классификация характеризует любую систему обработки транзакций, от простейших (P1, M1, H1, D1, S1) до более сложных многоузловых неоднородных окружений с поддержкой разнотипных наборов данных (Pn, Mn, Hn, Dn, Sn). В статье, написанной в 1991 г., эти авторы представили трехмерную классификацию, которую они применили для оценки различных исследовательских и коммерческих систем36).
В разд. 20.4 мы рассмотрели Encina - монитор TP корпорации Transarc - который включает множество библиотек и макросов, составляющих среду разработки Transactional C. Альтернативный способ задания директив обработки транзакций состоит в применении специального языка. В качестве примера рассмотрим язык InterBase Parallel Language (IPL), входящий в состав неоднородной распределенной cреды баз данных InterBase, которую мы обсуждали в гл. 6. IPL разработан с учетом поддержки высокой степени параллелизма и взаимодействия между субтранзакциями, принадлежащими общей глобальной транзакции37). IPL предназначался для поддержки транзакций разных типов (т. е. смешанных транзакций), а также как системно-независимый декларативный язык, обеспечивающий прозрачность управления транзакциями.
Ниже приведена общая структура субтранзакции IPL38).
subtrans ИМЯ_ТРАНЗАКЦИИ (АРГУМЕНТЫ): ТИП_РЕЗУЛЬТАТА at УЗЕЛ
use МЕНЕДЖЕР_РЕСУРСОВ between НАЧАЛЬНОЕ_ВРЕМЯ
and КОНЕЧНОЕ_ВРЕМЯ lasts МАКС_ВРЕМЯ_ВЫПОЛНЕНИЯ
guard УСЛОВИЕ_ПРИНУДИТЕЛЬНОГО_
ЗАВЕРШЕНИЯ_ТРАНЗАКЦИИ
beginexec
операции
endexec
beginconfirm
операции для подтверждения
субтранзакции
endconfirm
beginundo
операции для отмены
субтранзакции
endundo
endsubtrans;
Программа на IPL представляет собой блок, обрамленный ключевыми словами program - endprogram, и включает декларации записей и описания субтранзакций. Поскольку IPL постоянно развивается и в настоящее время в стадии исследований находится графический интерфейс, а также объектно-ориентированная версия этого языка, то за более полной информацией мы отсылаем читателя к материалам проекта InterBase, который ведется в Университете Пурдью.
Альтернативный подход к спецификации транзакций - использование языка, ориентированного не на глобальную схему или на специфическую для какого-либо продукта реализацию, а на нейтральную семантическую модель данных39). В связи с возрастающей ролью моделирования данных применение архитектур транзакций непосредственно к семантической модели также приобретает важное значение.
Значение этих средств определяется отчасти тем, что они способствуют интеграции концептуального моделирования процессов и данных. Классические процедуры интеграции 1970-х годов ориентировались, например, на отображение диаграмм потоков данных (DFD - Data Flow Diagram), на сущности и атрибуты диаграмм сущность-связь (ERD - Entity-Relation Diagram)40). Объектно-ориентированное моделирование обеспечивает определение объектов вместе с присущими им операциями, но ни тот ни другой вид моделирования не содержит средств для описания семантики транзакций. Выработка языков описания транзакций по отношению к некоторой модели данных с последующим переносом языковых средств в среду, обеспечивающую графическое представление вложенных, многозвенных и других развитых моделей транзакций, даст в будущем значительное увеличение продуктивности и надежности проектирования систем обработки транзакций.
Прежде чем завершить эту главу, обратимся еще раз к мониторам обработки транзакций третьего поколения, о которых упоминалось в разд. 20.2. К важнейшим характеристикам нового поколения средств обработки транзакций относятся следующие41).
Системы обработки транзакций так же, как и другие виды информационных и компьютерных систем, находятся в состоянии постоянного развития. Несмотря на то что концепция, например, вложенных транзакций была выработана еще в начале 80-х годов, если не раньше, однако только недавно модели транзакций, более прогрессивные, чем простейшие плоские, начали перемещаться из экспериментальных систем в коммерческие продукты.
Развитие сферы обработки транзакций неизбежно будет определяться такими факторами, как распределенность вычислительных ресурсов и потребность в межоперабельности. По этой причине, а также в силу того, что организации все активнее ищут средства для объединения и обеспечения управляемости своих информационных ресурсов, будет возрастать значение усилий, направленных на поддержку стандартизации, в частности на реализацию продуктов TP, интегрированных со средой DCE, совместимых со спецификациями OSI-TP, X/Open DTP.
Средства обработки транзакций имеют большое значение для поддержания целостности корпоративной информации. Хотя в области исследований сложных моделей транзакций были достигнуты значительные результаты (в частности, выработаны парадигмы, более приемлемые для распределенных систем, чем применявшиеся в течение многих лет в централизованных окружениях мэйнфреймов), однако они только сейчас начинают находить применение в реальных приложениях.
Ключевым свойством сложных моделей транзакций является возможность разбивать транзакцию на компоненты (субтранзакции). Субтранзакции, в зависимости от конкретной модели обработки, могут быть: (1) перезапущены при рестарте системы без необходимости заново выполнять всю транзакцию с самого начала; (2) обработаны синхронно или асинхронно относительно других субтранзакций; (3) подчинены некоторой "верховной (master) транзакции", которая имеет право прервать любую из своих субтранзакций, даже если та сама по себе нормально завершила свою часть обработки.
Важнейшая тенденция в сфере обработки транзакций - зарождение стандартов в двух областях: форматы и протоколы (т. е. стандартизация наборов пересылаемых сообщений и реакций получателя на каждый тип сообщения), а также прикладные программные интерфейсы (API); все это способствует обеспечению мобильности приложений обработки транзакций относительно различных платформ.
В связи с новыми потребностями сильно распределенных окружений пришло время пересмотреть многие устоявшиеся представления о моделях обработки транзакций, которые были выработаны для централизованных окружений мэйнфреймов. Модели одноуровневого управления не годятся для ситуации, когда в обработку транзакции вовлечено множество процессоров; существует множество способов группирования субтранзакций для поддержки функционирования сложных окружений.
Важное значение имеет правильный выбор одной из сложных моделей обработки транзакций с учетом специфики деятельности конкретной организации. Например, вложенные транзакции предоставляют исключительно гибкие способы управления субтранзакциями, но они очень сложны в реализации; при этом не во всех случаях такие возможности действительно необходимы. В некоторых ситуациях вполне приемлемой может оказаться модель многозвенных транзакций, в особенности если бизнес-функциям данной организации соответствуют схема асинхронной обработки субтранзакций.
Отметим также, что практически любому специалисту в области ИС необходимо хорошо ориентироваться в различных стандартах обработки транзакций.
1. U. Dayal et al. Third Generation TP Monitors: A Database Challenge. - Proceedings of the 1993 ACM SIGMOD.
2. J. L. Epinger, L.B. Mummert, A.Z. Spector, eds. Camelot and Avalon: A distributed Transaction Processing Facility. - San Francisco: Morgan Kaufmann Publishers, 1991.
3. J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. - San Francisco: Morgan Kaufmann Publishers, 1993.
4. A. D. Wolfe, Jr. Transarc Encina, Distributed Computing Monitor. - Patricia Seybold Group, November 1992.
1. J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. - San Francisco: Morgan Kaufmann Publishers, 1993, 3.
2. J. Gray and A. Reuter. Transaction Processing... 5.
3. U. Dayal et al. Third Generation TP Monitors: A Database Challenge. - Proceedings of the 1993 ACM SIGMOD, 394.
4. S. Dietzen. Distributed Transaction Processing with Encina and OSF DCE, Draft. - Transarc Corporation, September 1992. Provided courtesy of Transarc Corporation, Pittsburg, PA.
5. S. Dietzen. Distributed Tra nsaction Processing...
6. J. Gray. A Transaction Model. RJ2895. San Jose, CA: IBM Research Division, August 1980. Свойства ACID в контексте SQL и баз данных обсуждаются также в работе J. Melton and A. Simon. Understanding the New SQL: A Complete Guide. - San Francisco: Morgan Kaufmann Publishers, 1992, 39-40.
7. J. Gray and A. Reuter. Transaction Processing... 167.
8. J. Gray and A. Reuter. Transaction Processing... 171.
9. J. Gray and A. Reuter. Transaction Processing... 189.
10. J. Gray и A. Reuter обсуждают правила откатов до контрольных точек и различные вариации на эту тему с учетом правил, приведенных в J. Gray and A. Reuter. Transaction Processing... 189-190.
11. J. Gray and A. Reuter. Transaction Processing... 190.
12. J. Gray and A. Reuter. Transaction Processing... 192.
13. J. Gray and A. Reuter. Transaction Processing...
14. J. Gray and A. Reuter. Transaction Processing...
15. J. Gray and A. Reuter. Transaction Processing... 193.
16. J. Gray and A. Reuter. Transaction Processing... 195.
17. J.E.B. Moss. Nested Transactions: An Approach to Reliable Computing. - LCS-TR-260, Massachusetts Institute of Technology, Cambridg, MA, 1981, цитируется в J. Gray and A. Reuter. Transaction Processing... 195.
18. J.E.B. Moss. Nested Transactions... 196-197.
19. J.E.B. Moss. Nested Transactions... 197.
20. Gray и Reuter рассматривают многоуровневые, вложенные и другие виды транзакций в деталях и подробностях, которые выходят за рамки предмета данной книги. Заинтересованного читателя мы отошлем к материалам J. Gray and A. Reuter. Transaction Processing... 203-210.
21. U. Dayal et al. Third Generation TP Monitors... 394.
22. Dietzen. Distributed Transaction Processing... 7.
23. J.L. Epinger, L.B. Mummert, A.Z. Spector, eds. Camelot and Avalon: A distributed Transaction Processing Facility. - San Francisco: Morgan Kaufmann Publishers, 1991.
24. J. Gray and A. Reuter. Transaction Processing... 223.
25. Dietzen. Distributed Transaction Processing... 7-8.
26. A. Simon. Enterprise Computing. - New York: Bantam Books/ Intertext, 1992, а также A. Simon. Implementing the Enterprise. - New York: Bantam Books/Intertext, 1992, где можно найти множество примеров многоуровневых и модульных подходов в этой области.
27. A.D. Wolfe, Jr. Transarc Encina, Distributed Computing Monitor. - Patricia Seybold Group, November 1992, 5.
28. Encina: Enterprise Computing in a New Age. Product Overview, 8.
29. A.D. Wolfe, Jr. Transarc Encina...
30. Пример программы на языке Transactional C из A.D. Wolfe, Jr. Transarc Encina... 9.
31. J. Gray and A. Reuter. Transaction Processing... 260.
32. J. Gray and A. Reuter. Transaction Processing... 961.
33. J. Gray and A. Reuter. Transaction Processing...
34. J. Gray and A. Reuter. Transaction Processing... 84.
35. A. Left and C. Pu. A Classification of Transaction Processing Systems. - IEEE Computer, June 1991, 63-65.
36. A. Left and C. Pu. Transaction Processing Systems... 73.
37. J. Chen, A Elmagarmid, and O. Bukhres. The Interbase Parallel Language: Supporting Distributed Transaction Applications. - SERC-TR-119-P, Purdue University, West Lafayette, IN, July 1992.
38. J. Chen, A Elmagarmid, and O. Bukhres. The Interbase Parallel Language... 5.
39. S.B. Navathe and A. Balaraman. A Transaction Architecture for a General Purpose Semantic Data Model. В сборнике Proceedings of the Tenth International Conference on Entity-Relationship Approach: Bridging the Gap. ed. T.D. Teorey. - Ann Arbor, MI: University of Michigan, 1991.
40. Подробнее см. A. Simon. The Integrated CASE Tools Handbook. - Van Nostrand Reinhold/Intertext, 1993, Chap. 6.
41. На основе U. Dayal et al. Third Generation TP Monitors... 394-396 с комментариями автора настоящей книги.
|
|