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

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

464 Часть II. Типовые решения

Реализованный приведенным способом метод increment () должен вызываться

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

транзакции. Флаг is Locked срабатывает таким образом, что увеличение номера версии в

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

полнения фиксации. Это неправильно, поскольку основная идея оптимистического бло-

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

фиксации результатов.

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

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

транзакциях. Для этого к классу version можно добавить метод checkCurrent (), кото-

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

автономной блокировки без выполнения каких-либо обновлений.

В предыдущих фрагментах кода не показан метод delete, который вызывает SQL-

оператор для удаления объекта версии из базы данных. Если в результате выполнения

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

исключение ConcurrencyException. Это означает, что при удалении последнего из

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

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

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

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

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

момент удаления объекта версии гораздо сложнее. В качестве возможного решения

можно предложить хранение объектом версии количества своих владельцев и удаление

объекта, когда это количество достигнет нуля. К сожалению, подобная схема требует

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

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

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

тальных отсутствием номера собственной версии.

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

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

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

ствующего объекта домена.

class DomainObject...

private Long id;; private

Timestamp modified; private

String modifiedBy; private

Version version;

public void setSystemFields(Version version, Timestamp

modified, String modifiedBy) {

this.version = version;

this.modified = modified;

this.modifiedBy = modifiedBy;

}

Глава 16. Типовые решения для обработки задач автономного параллелизма 465

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

состоящим из объекта покупателя (корневой элемент) и его адресов. Метод create объ-

екта Customer будет создавать общий объект версии. Кроме того, у объекта Customer

есть метод get Address (), который создает объект адреса, передавая ему соответствую-

щий объект версии. Преобразователь AbstгасtMapper будет вставлять в базу данных за-

пись о новом объекте версии до вставки записей о соответствующих объектах домена.

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

только один раз.

class Customer extends DomainObject...

public static Customer create(String name) {

return new Customer(IdGenerator.

INSTANCE.nextldO

Version.create(), name, new ArrayList() ) ; }

class Customer extends DomainObject...

public Address addAddress(String linel, String city,

String state) {

Address address = Address.create(this, getVersion() ,

linel, city, state);

addresses.add(address);

return address;

}

class Address extends DomainObject...

public static Address create(Customer customer, Version

version, String linel, String city, String state) {

return new Address(IdGenerator.INSTANCE.nextld(), version,

customer, linel, city, state);

}

class AbstractMapper...

public void insert(DomainObject object) {

object.getVersion(). insert ();

Перед обновлением или удалением объекта домена преобразователь данных должен

увеличить номер соответствующей версии.

class AbstractMapper...

public void update(DomainObject object) {

object.getVersion().increment();

class AbstractMapper...

public void delete(DomainObject object) {

obj ect.getVersion().increment();

466 Часть II. Типовые решения

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

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

купателя.

class CustomerMapper extends AbstractMapper...

public void delete(DomainObject object) { Customer cust =

(Customer) object; for (Iterator iterator =

cust.getAddresses().

iterator

();

iterator.hasNext();) {

Address add = (Address) iterator.next();

MapperRegistry.getMapper(Address.class) .delete(add); }

super.delete(object);

cust.getVersion () .delete (); }

Пример: общая пессимистическая автономная блокировка (Java)

Для применения общей блокировки в пессимистической схеме блокирования нужно

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

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

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

этому на роль блокируемого маркера прекрасно подойдет общий объект версии. Весь код

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

Реализация нашей задачи связана с единственным спорным моментом. Как известно,

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

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

ровать, что в нашем распоряжении находятся самые свежие версии объектов? Самое про-

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

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

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

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

следние версии объектов агрегата, независимо от того, в какой момент системной тран-

закции произошла их загрузка.

class LoadCustomerCommand...

try {

Customer customer = (Customer)

MapperRegistry.getMapper(Customer.class).find(id);

ExclusiveReadLockManager.INSTANCE.acquireLock (

customer.getId(), AppSessionManager.getSession().getId());

customer.getVersion().increment();

TransactionManager.INSTANCE.commit(); }

catch (Exception e) {

TransactionManager.INSTANCE.rollback() ;

throw e;

}

Глава 16. Типовые решения для обработки задач автономного параллелизма 467

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

диспетчер блокировки или по крайней мере снабжать последний декоратором [20], кото-

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

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

казано в данном примере.

Пример: оптимистическая автономная блокировка корневого элемента (Java)

В данном примере используются почти все те же решения, что и в предыдущих при-

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

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

ект просто реализует метод increment (), чтобы облегчить наложение оптимистической

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

вания изменений будет применяться единица работы (Unit of Work, 205).

В качестве примера выбран агрегат, объекты которого связаны отношениями типа

"родитель—потомок", поэтому для перехода к корневому элементу будем последователь-

но перемещаться по ссылкам потомков к вышестоящим родителям. Для этого понадо-

бится немного изменить модель данных и модель домена.

class DomainObject...

private Long id;

private DomainObject parent;

public DomainObject(Long id, DomainObject parent) {

this.id = id;

this.parent = parent;

}

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

обходимо заблокировать корневой элемент.

class UnitOfWork...

public void commit() throws SQLException {

for (Iterator iterator = _modifiedObjects.iterator();

iterator.hasNext();) {

DomainObject object = (DomainObject) iterator.next ();

for (DomainObject owner = object; owner != null;

owner = owner.getParent ()) { owner.getVersion ()

.increment(); } } for (Iterator iterator =

_modifiedObjects.iterator();

iterator.hasNext ();) {

DomainObject object = (DomainObject) iterator.next (); Mapper

mapper = MapperRegistry.getMapper( object.getClass());

mapper.update(object); } }

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

ции нет "проколов". Стоит разработчику забыть вставить какую-нибудь строку кода, от-

носящуюся к применению блокировки, и вся схема блокирования окажется совершенно

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

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

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

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

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

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

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

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

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

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

вания.

Пожалуй, наиболее очевидное решение этой проблемы состоит в том, чтобы не дать

разработчикам совершить перечисленные ошибки. Выполнением наиболее важных про-

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

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

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

супертипов слоя (Layer Supertype, 491) и систем автоматической генерации кода, это пре-

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

468 Часть II. Типовые решения

Неявная блокировка (Implicit Lock)

Дейви

д Раис

Предоставляет инфраструктуре приложения или супертипу слоя право

накладывать автономные блокировки

Глава 16. Типовые решения для обработки задач автономного параллелизма 469

Принцип действия

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

пропустить при описании схемы блокирования, в инфраструктуру приложения. За не-

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

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

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

темы отопления обеспечивают жизнедеятельность в зданиях и городах). Обеспечить

корректное блокирование могут также средства автоматической генерации кода. Не-

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

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

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

блокирования. Тем не менее, все воплощения этой идеи, встречавшиеся мне на практи-

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

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

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

При использовании оптимистической автономной блокировки (Optimistic Offline Lock, 434)

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

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

UPDATE и DELETE и увеличение номера версии при изменении соответствующего объекта.

В свою очередь, при использовании пессимистической автономной блокировки (Pessi-

mistic Offline Lock, 445) список необходимых операций будет включать в себя применение

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

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

для считывания объекта) и высвобождение всех блокировок по окончании сеанса или

бизнес-транзакции.

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

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

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

ровки чтения/записи, предназначенной только для выполнения записи. Да, эти бло-

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

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

неявным способом могут привести к ряду проблем. Во-первых, те условия, в которых

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

объекта в единице работы (Unit of Work, 205)), не гарантируют аварийного завершения

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

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

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

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

должен переделывать свою работу.

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

ограничивают возможность параллельной работы в системе. В этом случае отказ от не-

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

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

область бизнес-требований. Тем не менее нам все-таки нужно гарантировать, что все

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

изменений. Эту проверку можно поручить инфраструктуре приложения. Отсутствие

470 Часть II. Типовые решения

блокировки на момент фиксации изменений является ошибкой программирования и,

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

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

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

ключены.

Говоря о неявной блокировке, следует сделать несколько предостережений. Ее при-

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

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

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

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

заботиться о предотвращении взаимоблокировок. Как только разработчики перестают

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

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

ной блокировки.

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

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

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

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

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

Назначение

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

луй, самых простых, не имеющих инфраструктуры). Задумайтесь: риск забыть какую-

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

Пример: неявная пессимистическая автономная блокировка (Java)

Рассмотрим систему, использующую монопольную блокировку чтения. Архитектура

этой системы включает в себя модель предметной области (Domain Model, 140), а для

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

преобразователи данных (Data Mapper, 187). При использовании монопольной блокиров-

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

позволить бизнес-транзакции совершать какие-либо действия надданным объектом.

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

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

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

вом метода find () или перемещением по графу объекта. Для реализации неявной бло-

кировки можно применить декоратор [20], чтобы добавить к поведению преобразователя

требующуюся функциональность блокирования. Для этого напишем преобразователь

LockingMapper, который будет применять блокировку перед попыткой найти объект.

interface Mapper...

public DomainObject find(Long id);

public void insert(DomainObject ob j) ;

public void update(DomainObject ob j) ;

public void delete(DomainObject obj);

Глава 16. Типовые решения для обработки задач автономного параллелизма 471

class LockingMapper implements Mapper...

private Mapper impl;

public LockingMapper(Mapper impl) {

this.impl = impl; } public

DomainObject find(Long id) {

ExclusiveReadLockManager.INSTANCE.acquireLock(

id, AppSessionManager.getSession().getId());

return impl.find(id); } public void

insert(DomainObject obj ) {

impl.insert(obj ) ; } public void

update(DomainObject obj) {

impl.update(obj); } public void

delete(DomainObject obj) {

impl.delete(obj);

}

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

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

рить, нет ли у сеанса существующей блокировки на данный объект. Если бы вместо

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

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

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

обновлением или удалением соответствующего объекта.

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

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

как изменяется поведение преобразователей, содержащихся в реестре (Registry, 495).

LockingMapperRegistry implements MappingRegistry...

private Map mappers = new HashMapO;

public void registerMapper(Class els,

Mapper mapper) {

mappers.put(els, new LockingMapper

(mapper)

);

}

public Mapper getMapper(Class els) {

return (Mapper) mappers.get(els);

}

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

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

рис. 16.5.

472 Часть II. Типовые решения

Рис. 16.5. Схема работы преобразователя LockingMapper

Глава 17

Типовые решения

для хранения

состояния сеанса

Сохранение состояния сеанса на стороне клиента (Client Session State)

Сохраняет состояние сеанса на стороне клиента

Принцип действия

Даже если дизайн корпоративной системы полностью ориентирован на использова-

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

нибудь) приходится располагать на стороне клиента. В некоторых приложениях на сто-

рону клиента помещают всю информацию о состоянии сеанса. В этом случае клиент пе-

редает серверу все сведения о сеансе вместе с каждым запросом, а сервер возвращает все

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

стью отказаться от сохранения состояний сеанса.

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

зуется объект переноса данных (Data Transfer Object, 419). Он может сериализовать свое

содержимое для передачи по сети, тем самым позволяя перемещать весьма сложные

структуры данных.

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

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

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

образом). Гораздо более удачным решением является хранение состояний сеансов в со-

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

екте переноса данных. В любом случае, это не такая уж серьезная проблема.

С HTML-интерфейсами дело обстоит немного сложнее. Существует три основных

способа сохранения состояния сеанса на стороне клиента: параметры адреса URL,

скрытые поля и файлы cookie.

Использование параметров адреса URL хорошо подходит для работы с небольшим

количеством данных. Вообще говоря, для отображения Web-страницы с результатами

выполнения запроса все адреса URL принимают то или иное количество параметров