Фаулер М. Архитектура корпоративных программных приложений

Подождите немного. Документ загружается.

84 Часть I. Обзор

Типовые решения представлений

Когда речь заходит о возможных способах реализации представлений, внимания за-

служивают три основных типовых решения: представление с преобразованием (Transform

View, 379), представление по шаблону (Template View, 368) и двухэтапное представление

(Two Step View, 383). По существу, выбор сводится к одному из двух вариантов — вос-

пользоваться представлением с преобразованием или представлением по шаблону в базовой

одноэтапной версии либо усложнить любое из них до уровня двухэтапного представления.

Я обычно начинаю с выбора между представлением по шаблону и представлением с

преобразованием. Первое позволяет оформлять представление в соответствии со структу-

рой страницы и вставлять в нее специальные маркеры, отмечающие позиции фрагментов

динамического содержимого. Представление по шаблону поддерживается целым рядом

популярных платформ, многие из которых основаны на модели страниц сервера (скажем,

ASP, JSP и PHP) и позволяют внедрять в текст страницы код на полнофункциональном

языке программирования. Такое решение отличается мощностью и гибкостью; если код

сложен и запутан, задача сопровождения системы чрезвычайно затрудняется. Поэтому

использование технологий страниц сервера требует аккуратности и последовательности в

обособлении логики кода от структуры страницы, которое зачастую достигается при по-

средничестве вспомогательного (helper) объекта.

Примером реализации представления с преобразованием может служить XSLT. Эта

технология оказывается весьма эффективной, если данные домена сохраняются в форма-

те XML или допускают быстрое преобразование в XML. Входной контроллер выбирает

подходящую таблицу стилей XSLT и применяет ее к XML-коду, описывающему модель.

Если представление задается с помощью процедурных сценариев, для написания кода

можно пользоваться представлением с преобразованием, представлением по шаблону или

"смесью" двух подходов в любой подходящей пропорции.

Далее принимается решение о том, использовать одноэтапную версию представления

(рис. 4.2) или прибегнуть к соответствующей форме двухэтапного представления. Одно-

этапный вариант предусматривает преимущественно по одному компоненту представле-

ния для каждого интерфейсного экрана приложения. Код представления получает дан-

ные домена и преобразует их в формат HTML. Я говорю "преимущественно", поскольку

схожие "логические экраны" (logical screens) могут делить представления между собой.

Впрочем, в большинстве ситуаций уместно полагать, что каждое представление относится

к одному экрану.

Двухэтапное представление (рис. 4.3) разделяет процесс на две стадии: на первой на

основе данных домена формируется логический экран, который на второй стадии транс-

формируется в код HTML Для каждого экрана существует одно представление первого

этапа, но для приложения в целом — только одно представление второго этапа.

Достоинство двухэтапного представления заключается в том, что решение о варианте

преобразования в HTML принимается в одном месте. Это существенно облегчает задачу

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

отредактировать данные единственного объекта. Разумеется, воспользоваться таким пре-

имуществом удастся только в том случае, когда логическое представление остается постоян-

ным, т.е. различные экраны компонуются по одному принципу. Сайты, спроектированные по

излишне сложным схемам, единообразием логической структуры обычно не отличаются.

Глава 4. Представление данных в Web 85

Рис. 4.3. Пример двухэтапного представления

86 Часть I. Обзор

Типовое решение двухэтапное представление хорошо проявляет себя в ситуациях, где

службы Web-приложения используются многочисленными клиентами (например, посети-

телями сайта системы бронирования авиабилетов). Удовлетворяя требованиям компоновки

одного логического экрана, каждая из версий клиентского приложения, отвечающая опре-

деленному варианту реализации второго этапа представления, может иметь другой внеш-

ний вид. Таким же образом двухэтапное представление может быть использовано и для об-

служивания разных устройств вывода, когда необходимо предусмотреть отдельные реали-

зации второго этапа представления, скажем, для обычного Web-обозревателя и карманного

компьютера. К сожалению, наличие общего логического экрана может сыграть отрица-

тельную роль в случае, когда речь идет о двух существенно отличающихся пользовательских

интерфейсах (например, об интерфейсе Web-обозревателя и сотового телефона).

Типовые решения входных контроллеров

Существует два типовых решения проблемы организации входных контроллеров. Наи-

более общий подход состоит в создании объекта входного контроллера для каждой страни-

цы Web-сайта. В простейшем случае подобный контроллер страниц (Page Controller, 350)

можно оформить в виде страницы сервера, сочетая в нем функции представления и вход-

ного контроллера. Во многих ситуациях, однако, легче выделить входной контроллер в

самостоятельный объект. Нередко взаимно однозначного соответствия между контролле-

рами страниц и представлениями не существует. Точнее говоря, следует иметь контроллер

страниц для каждого действия, где действием является кнопка или гиперссылка. В боль-

шинстве случаев действия соответствуют страницам, но бывает и так, что ссылка, на-

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

На входной контроллер возлагаются две основные обязанности: обработка HTTP-

запроса и принятие решения о том, что с ним делать дальше, которые зачастую имеет

смысл разделить, поручив первую функцию странице сервера, а вторую — вспомогатель-

ному объекту. В то же время типовое решение контроллер запросов (Front Controller, 362)

предусматривает использование единственного объекта, предназначенного для обработ-

ки всех запросов. Обработчик интерпретирует полученный адрес URL, определяет, с ка-

кого рода запросом он имеет дело, и создает отдельный объект для дальнейшего обслу-

живания запроса. Таким образом удается централизовать деятельность по обработке всех

HTTP-запросов в рамках единого объекта и избежать необходимости изменения конфи-

гурации Web-сервера в случае модификации структуры действий сайта.

Дополнительные источники информации

В большинстве книг по Web-технологиям найдется пара глав, посвященных удачным

образцам организации Web-серверов (подобная информация, однако, часто изобилует не-

нужными деталями). Прекрасный пример Java-проекта обсуждается в главе 9 руководства

[9]. Лучший источник информации о других типовых решениях — книга [3]; многие из них

не привязаны к Java и носят универсальный характер. Терминология, касающаяся разделе-

ния функций входного контроллера и контроллера приложения, заимствована из [25].

Глава 5

Управление

параллельными

заданиями

Мартин Фаулер иДейвид Райе

Параллельное (concurrent) выполнение операций — одна из наиболее сложных дис-

циплин в области разработки программного обеспечения. Проблемы параллелизма

возникают всякий раз, когда, скажем, несколько процессов или потоков вычислений

предпринимают попытки манипуляций одними и теми же элементами данных. Вос-

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

возможные сценарии развития событий, способные привести к тем или иным непри-

ятностям, крайне сложно. Что бы вы ни делали, всегда кажется, что какие-то вещи

упущены. Более того, параллельные операции трудно тестировать. Всем нам нравятся

средства автоматического тестирования, сопровождающие процессы разработки про-

граммного обеспечения от начала и до конца, но найти тесты, которые смогли бы убе-

дить в достаточной надежности параллельного кода, практически невозможно.

Забавно и парадоксально, что с возрастанием степени параллелизма операций в кор-

поративных приложениях разработчики все меньше заботятся о сопутствующих проблемах.

Причиной подобного легкомысленного отношения служит наличие готовых подсистем —

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

вы манипулируете данными внутри транзакции, будьте уверены, что ничего плохого с ними

не случится.

Впрочем, это не значит, что проблемами управления параллельными заданиями мож-

но полностью пренебречь, так как многие аспекты взаимодействия приложения и систе-

мы нельзя свести к контексту единой транзакции, обращенной к базе данных, — во

многих случаях приходится иметь дело с данными, модифицируемыми несколькими

транзакциями. Последняя задача получила название автономного параллелизма (offline

concurrency).

Еще одна ситуация, в которой феномен параллелизма проявляет свою угрожающую

сущность, связана с серверами приложений, поддерживающими множество одновремен-

но протекающих потоков вычислений. Впрочем, автору прикладной программы беспо-

коиться не о чем — все обязанности принимает на себя серверная платформа.

88 Часть I. Обзор

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

базовыми понятиями; с этого и начнем. Однако не стоит трактовать эту главу как сколь-

ко-нибудь полное введение в технологии управления параллельными операциями, так

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

Вы познакомитесь с аспектами параллелизма, имеющими отношение к корпоративным

программным приложениям. Затем на ваш суд будут представлены типовые решения в

области управления параллельными заданиями в автономном режиме и некоторые под-

ходы к обеспечению многопоточного функционирования серверов приложений.

На протяжении всей главы для иллюстрации концепций параллелизма приводятся

примеры из области, которая, вероятно, вам хорошо знакома: речь идет о системах кон-

троля версий исходного кода, которые применяются командами разработчиков для ко-

ординации вносимых изменений. (Между прочим, если вы не осведомлены о подобных

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

Проблемы параллелизма

Обозначим некоторые принципиальные проблемы обеспечения параллельной работы

программньгх приложений. На преодоление именно этих проблем направлены усилия

систем управления параллельными заданиями. Впрочем, трудности связаны не только

с параллелизмом — управляющие системы, разрешая одно, часто усугубляют другое!

Самый простой для восприятия пример — утраченные изменения (lost updates). Пред-

положим, что некий Мартин открывает для редактирования файл с исходным кодом

программы, намереваясь за пару минут подправить текст метода checkConcurrency.

В то же самое время ни о чем не подозревающий Дейвид обращается к тому же файлу,

чтобы модифицировать метод updatelmportantParameter. Дейвид справляется со

своим заданием очень быстро — настолько быстро, что, приступив к работе позже Мар-

тина, успевает завершить ее раньше... к несчастью. В момент открытия Мартином файл

еще не содержал изменений, внесенных Дейвидом, поэтому, сохраняя результат, Мартин

запишет поверх содержимого файла свою копию данных, и редакция Дейвида будет без-

возвратно потеряна.

А эффект несогласованного чтения (inconsistent read) возникает в ситуациях, когда счи-

тываются две корректные сами по себе порции данных, которые, однако, не могут су-

ществовать в один и тот же момент времени. Допустим, тому же вездесущему Мартину

захотелось узнать, сколько классов содержит пакет поддержки параллельной работы,

который состоит из двух вложенных пакетов, реализующих протоколы блокирова-

ния и протоколирования действий транзакций. Мартин заглядывает в пакет блоки-

рования и видит в нем семь классов. В этот момент звонит телефон, и приятель, ко-

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

неутомимый Дейвид, наконец, устраняет досадную ошибку в коде метода четырех-

фазного блокирования и вводит два новых класса в пакет блокирования и три, в до-

бавление к имеющимся пяти, — в пакет протоколирования. Чувство долга берет верх над

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

в пакете протоколирования восемь классов и приходит к глубокомысленному выводу

о том, что общее количество классов равно пятнадцати.

Глава 5. Управление параллельными заданиями 89

Конечно, 15 — это неверный ответ. Правильным был бы такой: 12 до внесения изме-

нений Дейвидом и 17 — после. Любой из них корректен, хотя в какой-то момент време-

ни, возможно, неактуален, но число 15, полученное на основе несогласованных выводов,

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

Обе проблемы выражаются в потере достоверности (correctness) информации и в не-

корректном поведении системы, чего можно было бы избежать, если бы два человека не

обращались к одним и тем же данным одновременно. Впрочем, если бы речь шла только

о недостоверности, проблемы не были бы столь серьезными. Собственно говоря, можно

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

к порции данных в определенный момент времени. Это поможет сберечь достоверность

информации, но снизит возможности параллельного выполнения операций по ее обра-

ботке. Основополагающая проблема любой модели программирования параллельных

операций заключается не только в сохранении корректности данных, но и в обеспечении

максимальной степени параллелизма {живучести (liveness) системы). Зачастую приходится

поступаться корректностью в угоду параллельности; величина такой жертвы определя-

ется, с одной стороны, серьезностью нештатных ситуаций, возникающих из-за возмож-

ной недостоверности или неактуальности данных, а с другой — действительным уровнем

потребностей в выполнении операций в параллельном режиме.

Это далеко не все проблемы, которые могут подстерегать разработчиков систем па-

раллельной обработки данных, но, как можно полагать, главные. Для их разрешения

используются различные управляющие механизмы. Увы, за все приходится платить.

Нередко процесс преодоления одних проблем способствует появлению других — хотя

и менее серьезных, но неизбежных. Отсюда следует один важный вывод: если пробле-

мы, связанные с параллельной обработкой данных, "терпимы", постарайтесь отказать-

ся от идеи использования управляющего механизма.

Контексты выполнения

Все операции, выполняемые системой, протекают в определенном контексте, при-

чем зачастую более чем в одном. Общепринятой терминологии для обозначения контек-

стов выполнения не существует, и потому ниже введены определения, которые будут ис-

пользоваться в дальнейшем.

В аспекте взаимодействия программной системы с внешним миром можно выделить

два важных контекста — запрос и сеанс. Запрос (request) соответствует отдельно взятому

обращению к системе со стороны внешнего субъекта-клиента. Обработка запроса яв-

ляется прерогативой сервера; обычно подразумевается, что клиент, инициировавший

запрос, ожидает ответа на него. При использовании некоторых протоколов клиенту раз-

решается прерывать запрос до получения ответа, но такие ситуации встречаются сравни-

тельно редко. Чаще клиент имеет возможность послать другой запрос, противоречащий

исходному (скажем, отправить запрос с заказом, а затем отменить заказ). По мнению

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

нести эту информацию до сервера.

Сеанс (session) — это долговременный процесс взаимодействия клиента и сервера.

В частном случае сеанс может включать только один запрос, но более характерна ситуа-

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

90 Часть I. Обзор

последовательности. Обычно сеанс начинается с подключения клиента к системе и слу-

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

к базе данных и осуществление одной или нескольких бизнес-транзакций (о них речь

идет ниже). В завершение сеанса пользователь отключается от системы явно либо просто

закрывает приложение, полагая, что система отреагирует на это надлежащим образом.

Программное обеспечение сервера корпоративных приложений может выступать

в двух ипостасях — как сервер для клиента приложения и как клиент других систем.

Поэтому нужно иметь в виду и возможность одновременного протекания нескольких

сеансов с участием сервера (например, HTTP-сеанса с клиентом и сеанса взаимодейст-

вия с СУБД).

Рассмотрим другую пару понятий, происходящих из предметной области операцион-

ных систем, — "процесс" и "поток вычислений". Процесс (process) — это всеобъемлющий

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

данных от внешнего мира. Поток вычислений (thread) — более "легковесный" активный

агент; в контексте одного процесса может функционировать целое множество потоков.

Модель многопоточного программирования находит самое широкое применение, по-

скольку обеспечивает высокий уровень использования вычислительных ресурсов благо-

даря возможности формирования многочисленных запросов в русле единого процесса.

Однако потоки, как правило, имеют доступ к одним и тем же массивам оперативной

памяти, что приводит к естественным проблемам. Некоторые среды позволяют управ-

лять доступом к ресурсам и создавать изолированные потоки (isolated threads), которые,

в частности, способны обращаться к собственным областям памяти.

Одна из трудностей восприятия контекстов выполнения состоит в том, что они

в действительности не упорядочены в такой степени, как того хотелось бы. В теории

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

всего времени его протекания. Поскольку процессы в достаточной мере изолированы

друг от друга, это могло бы снизить опасность возникновения конфликтов из-за па-

раллелизма. На сегодня, однако, не известна ни одна серверная платформа, которая

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

нового процесса для обработки каждого поступившего запроса; именно такая схема

использовалась в ранних Web-системах, основанных на сценариях Perl. Сейчас ее ста-

раются избегать, так как старт процесса сопряжен с расходованием избыточных ресур-

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

в каждый момент времени; это позволяет избавиться от многих проблем, обусловлен-

ных параллельным функционированием нескольких потоков.

При работе с системой баз данных следует различать еще один важный контекст

выполнения — контекст транзакции (transaction). Транзакции способны соединять

в себе несколько запросов, которые клиенту хотелось бы трактовать как единый за-

прос. Команды, составляющие транзакцию, могут быть адресованы приложением

к СУБД (системные транзакции) или пользователем к приложению (бизнес-транзак-

ции). Эти термины обсуждаются ниже.

Глава 5. Управление параллельными заданиями 91

Изолированность и устойчивость данных

Проблемы параллельного выполнения программ известны уже давно, и за это время

предложено немало вариантов их решения. Для корпоративных приложений особенно

важны два решения: поддержка изолированности (isolation) и обеспечение устойчивости

(immutability) данных.

Подобные проблемы возникают в ситуациях, когда несколько активных агентов, та-

ких, как процессы или потоки вычислений, обращаются к одной и той же порции ин-

формации. Один из вариантов разрешения возможных конфликтов состоит в изоляции

данных таким образом, чтобы к любому их элементу мог адресоваться только один агент.

Процессы прикладной программы протекают так же, как их аналоги уровня операцион-

ной системы: процесс получает в свое безраздельное владение участок оперативной па-

мяти, и только этот процесс способен считывать и сохранять ассоциированные с ним

данные. Схожим образом действуют и схемы блокирования файлов, применяемые во

многих популярных приложениях. Если файл открыт Мартином, в этот период никто

другой открыть его уже не сможет; в крайнем случае система разрешит обратиться к фай-

лу в режиме "только для чтения" и просмотреть ту версию данных, которая соответство-

вала началу сеанса работы Мартина. На протяжении всего сеанса никто не сможет изме-

нить содержимое файла и увидеть какую бы то ни было промежуточную информацию,

сохраняемую Мартином.

Поддержка изолированности — весьма важный технологический прием, позволяющий

снизить вероятность возникновения ошибок. Слишком часто разработчики сами заго-

няют себя в угол, используя инструментальные средства управления, которые вынужда-

ют неотрывно держать руку на пульсе событий. Заставляя программу функционировать в

некой изолированной зоне, мы избавляемся от такой необходимости. Таким образом,

добротное проектирование приложения предполагает успешный поиск таких зон и пере-

нос возможно большей части кода в их контекст.

Проблемы, связанные с параллельным доступом к данным, возникают только тогда,

когда общие фрагменты таких данных подвержены изменениям. Один из естественных

способов предотвращения потенциальных конфликтов заключается в обнаружении ус-

тойчивых (immutable) элементов информации. Совершенно очевидно, что придать статус

устойчивости всем данным не удастся, поскольку основное назначение многих систем

как раз и состоит в обеспечении средств модификации информации. Но если определить

некоторые порции данных как устойчивые или, по меньшей мере, устойчивые в продол-

жение некоторых периодов, можно ослабить ограничения параллельного доступа. Еще

одна альтернатива — отделить приложения, функционирующие в режиме "только для

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

значительно упростит логику управления доступом.

Стратегии блокирования

Что может произойти при наличии определенных данных, которые подвержены из-

менениям и не допускают возможности изоляции? Если говорить в самом широком

92 Часть I. Обзор

смысле, существует два вида стратегий управления параллельными заданиями — опти-

мистические (optimistic) и пессимистические (pessimistic).

Предположим, что Мартину и Дейвиду позарез нужно редактировать файл Customer

одновременно. Используя схему оптимистического блокирования (optimistic locking), тот

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

Завершая работу первым, Дейвид без проблем сохраняет изменения в основном файле.

Если в то же самое время записать данные в файл пытается и Мартин, система контроля

версий, обнаружив конфликт, должна запретить эту операцию и позволить Мартину

принять осмысленное решение по выходу из сложившейся ситуации. При реализации

стратегии пессимистического блокирования (pessimistic locking) первый пользователь, захва-

тивший файл, препятствует открытию файла всеми другими пользователями. Если в та-

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

тех пор, пока тот не будет освобожден.

Стратегии удобно воспринимать следующим образом: оптимистическое блокирова-

ние дает возможность обнаруживать конфликты, в то время как пессимистическое по-

зволяет их предотвращать. В реальных системах контроля версий исходного программ-

ного кода применяются обе стратегии, хотя сегодня большинству разработчиков по нраву

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

оптимистическое блокирование не является "блокированием" в привычном смысле сло-

ва, но, на наш взгляд, этот термин слишком удобен и широко распространен, чтобы его

можно было легко отвергнуть.)

Обоим подходам присущи как достоинства, так и недостатки. Изъян схемы пессими-

стического блокирования состоит в снижении степени параллелизма операций. Когда

Мартин работает с заблокированным файлом, всем остальным желающим (в частности,

Дейвиду) приходится ждать своей очереди. Если вам приходилось пользоваться система-

ми контроля версий, основанными на модели пессимистического блокирования, вы со-

гласитесь, что неопределенно долгое ожидание способно порой довести до бешенства.

В ситуации с корпоративными данными проблема еще более обостряется, поскольку ре-

дактируемые порции информации не позволяется даже считывать; что же говорить тогда

о возможности их совместного параллельного изменения!

Стратегия оптимистического блокирования предоставляет гораздо больше свободы,

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

блемы появляются при возникновении конфликтов версий данных. Каждый, кто обра-

щается к файлу после внесения изменений Дейвидом, должен проверить оставленную им

версию файла, определить, как осуществить слияние собственных результатов с редакци-

ей Дейвида, и зарегистрировать новую версию. Если речь идет об исходном программном

коде, все это не особенно трудно: во многих случаях системы контроля версий способны

осуществить слияние автоматически, а если по каким-либо причинам это невозможно,

они предлагают удобные средства поиска и воспроизведения внесенных исправлений.

Но выполнить слияние нескольких версий одной и той же порции бизнес-данных на-

много сложнее, поэтому зачастую проще поступиться затратами времени и сил и все на-

чать сначала.

Главное, что следует учитывать, осуществляя выбор между оптимистическим и пес-

симистическим блокированием, — это частота возникновения и степень опасности кон-

фликтов. Если конфликты относительно редки или их последствия незначительны,

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

Глава 5. Управление параллельными заданиями 93

высокий уровень параллелизма операций и более проста в реализации. Если же кон-

фликты грозят головной болью, уместнее избрать технологию пессимистического блоки-

рования.

Ни один из подходов не свободен от недостатков, серьезных и не очень. Более того,

используя любую стратегию блокирования, вы можете легко спровоцировать новые

проблемы, ничуть не проще тех, с которыми вы пытались совладать. Оставим обсуж-

дение всех тонкостей предмета авторам соответствующих специализированных изда-

ний, а здесь отметим лишь отдельные моменты.

Предотвращение возможности несогласованного чтения данных

Рассмотрим следующую ситуацию. Мартин редактирует текст класса Customer, до-

бавляя некоторые вызовы методов класса Order. Тем временем Дейвид исправляет ин-

терфейс класса order. Дейвид компилирует код и фиксирует его новую версию; Мартин,

как ни странно, делает то же самое. Но общая часть кода теперь неверна, поскольку Мар-

тину неизвестно, что класс Order подвергся негласной модификации. Одни системы

контроля версий способны распознать подобные попытки несогласованного чтения

(inconsistent read), в то время как другие для достижения согласованности требуют вмеша-

тельства извне.

Проблемой несогласованного чтения нередко пренебрегают просто потому, что по-

вышенное внимание уделяют ситуациям, чреватым утратой внесенных изменений.

В рамках технологий пессимистического блокирования разработаны удачные варианты

решения проблемы за счет использования специфических режимов блокирования, со-

провождающих операции чтения и записи. В первом случае применяют общие (shared)

блокировки, а во втором — монопольные (exclusive). Допускается одновременный захват

многих общих блокировок одной и той же порции данных, причем, если хотя бы одна

общая блокировка активизирована, монопольную блокировку запросить не удастся. Ес-

ли же кто-то захватил монопольную блокировку, все попытки получения любых блоки-

ровок тех же данных будут отвергнуты. Подобная схема пессимистического блокирова-

ния полностью устраняет опасность несогласованного чтения.

Механизмы выявления конфликтов, используемые в стратегиях оптимистического

блокирования, обычно основаны на неких схемах маркирования данных. В качестве

маркеров используются те или иные хронологические признаки или счетчики. Для обна-

ружения утраченных изменений система сравнивает маркер версии измененных данных

с маркером версии общих исходных данных. Если маркеры совпадают, изменение всту-

пает в силу.

Выявление фактов несогласованного чтения осуществляется по тому же принципу:

каждая часть считанных данных нуждается в маркере, который сравнивается с маркером

оригинала. Любое несоответствие указывает на наличие конфликта.

Контроль за считыванием информации часто сопряжен с ненужными проблемами из-

за разногласий на почве обращения к данным, которые в действительности того не за-

служивают. Чтобы уменьшить тяжесть подобного бремени, необходимо четко размеже-

вать данные по степени их важности. Трудность заключается в том, что не всегда ясно,

каково истинное назначение тех или иных элементов информации. Почтовый код в адре-

се может выглядеть как излишество, но если представить, что при расчете налогов учи-

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