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

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

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

}

protected HttpServletResponse getRspO {

return rsp;

}

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

блокировки существующего сеанса. Мы также добавляем класс LockRemover, реали-

зующий интерфейс HttpSessionBindingListener, который будет удалять Все блоки-

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

щего НТТР-сеанса.

class LockRemover implements HttpSessionBindingListener...

private String sessionld;

public LockRemover(String sessionld) {

this.sessionld = sessionld; }

public void valueUnbound(HttpSessionBindingEvent event) {

try {

beginSystemTransaction ();

ExclusiveReadLockManager . INSTANCE . relaseAHLocks (

this.sessionld);

commitSystemTransaction() ;

} catch (Exception e) {

handleSeriousError(e) ; } }

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

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

системной транзакции. Для этого можно модифицировать поведение команды с помо-

щью декоратора [20], представленного объектом TransactionalCommand. Реааизуя объ-

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

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

транзакции. Методы, определяющие рамки системной транзакции, зависят от контекста

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

ключения ConcurrencyException (а в нашем примере— и всех других исключений).

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

вении конфликта.

class TransactionalCommand implements Command...

public TransactionalCommand(Command impl) {

this.impl = impl;

}

public void process() throws Exception {

beginSystemTransaction(); try {

impl.process();

commitSystemTransaction(); }

catch (Exception e) (

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

rollbackSystemTransaction() ; throw

e; } }

Теперь нужно написать сервлет, выполняющий роль контроллера, и конкретные

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

транзакциями; конкретные классы команд необходимы для установки контекста бизнес-

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

где это потребуется.

class ControllerServlet extends HttpServlet...

protected void doGet(HttpServletRequest req,

HttpServletResponse rsp) throws ServletException, IOException {

try {

String cmdName = req.getParameter("command");

Command cmd = getCommand(cmdName); cmd.init(req,

rsp); cmd.process(); } catch (Exception e) {

writeException(e, rsp.getWriter() ) ; } }

private Command getCommand(String name) {

try {

String className = (String) commands.get(name); Command

cmd = (Command) Class.forName( className).newlnstance();

return new TransactionalCommand(cmd); }

catch (Exception e) {

e.printStackTrace();

throw new SystemException("unable to create command

object for " + name);

}

class EditCustomerCommand extends BusinessTransactionCommand...

public void process() throws Exception {

startNewBusinessTransaction(); Long customerld =

new Long(getReq().getParameter(

"customer_id"));

ExclusiveReadLockManager.INSTANCE.acquireLock(

customerld, AppSessionManager.getSession().getld());

Mapper customerMapper =

MapperRegistry.INSTANCE.getMapper(Customer.class);

Customer customer = (Customer) customerMapper.find(

customerld);

getReq().getSession().setAttribute("customer", customer);

forward ( "/editCustomer . jsp" ) ,-}

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

class SaveCustomerCommand extends BusinessTransactionCommand...

public void process() throws Exception {

continueBusinessTransaction();

Customer customer = (Customer)

getReq().getSession().getAttribute("customer");

String name = getReq().getParameter("customerName");

customer.setName(name); Mapper customerMapper =

MapperRegistry.INSTANCE.getMapper(Customer.class);

customerMapper.update(customer);

ExclusiveReadLockManager.INSTANCE.releaseLock(

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

forward("/customerSaved.j sp"); }

Описанные команды предотвращают одновременный доступ двух сеансов к одному и

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

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

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

Поскольку диспетчер блокировки выполняет проверку на наличие существующей бло-

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

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

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

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

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

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

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

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

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

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

полноценное архитектурное решение.

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

Блокировка с низкой степенью детализации (Coarse-Grained Lock)

Дейвид Раис и Мэттью Фоммел

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

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

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

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

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

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

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

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

ного механизма может стать затруднительной. А что, если группы будут иметь более

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

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

ровки (Optimistic Offline Lock, 434)), блокирование большой группы объектов значительно

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

номной блокировки (Pessimistic Online Lock, 445) наличие большой группы объектов крайне

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

таблице блокировки.

Типовое решение блокировка с низкой степенью детализации накладывает блокировку

сразу на группу объектов. Это не только упрощает применение блокировки, но и осво-

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

из них.

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

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

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

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

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

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

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

сти загрузить) как можно меньше объектов группы.

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

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

тот же (а не такой же) объект версии (рис. 16.2). Увеличение номера версии приведет к

наложению на группу объектов общей блокировки (shared lock). В этом случае для миними-

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

общий объект версии.

Рис. 16.2. Совместное использование объекта версии

Применение общей пессимистической автономной блокировки требует, чтобы все чле-

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

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

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

кируемого маркера прекрасно подойдет общий объект версии (рис. 16.3).

Рис. 16.3. Блокирование совместно используемого объекта версии

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

Эрик Эванс (Eric Evans) и Дейвид Сигель (David Siegel) [15] определяют агрегат

(aggregate) как совокупность взаимосвязанных объектов, рассматриваемых с точки внесе-

ния изменений как единое целое. У каждого агрегата есть корневой элемент (root), яв-

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

(boundary), определяющая, какие объекты входят в агрегат. Перечисленные свойства аг-

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

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

менты. Блокирование агрегата представляет собой еще одну форму блокировки с низкой

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

элемента (root lock) (рис. 16.4). По определению блокирование корневого элемента рас-

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

единственной точкой соперничества за доступ к группе объектов, входящих в агрегат.

Рис. 16.4. Блокирование корневого элемента

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

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

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

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

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

нением каждого объекта агрегата с корневым элементом или же последовательностью

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

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

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

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

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

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

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

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

перемещения к корневому элементу необходимо применять загрузку по требованию (Lazy

Load, 220). Это позволит не только избежать загрузки ненужных объектов, но и справить-

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

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

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

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

и очень плохо.

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

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

корневой элемент.

Обе реализации блокировки с низкой степенью детализации — в виде общей блокиров-

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

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

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

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

привести к падению производительности. Вообще говоря, сочетание блокировки корне-

вого элемента и пессимистической автономной блокировки удачным не назовешь. К тому

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

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

чие последних версий. И наконец, большие ограничения на выбор реализации наклады-

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

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

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

Назначение

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

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

гатов. Представьте себе объект, содержащий коллекцию предметов имущества, сдавае-

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

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

в коллекцию. Поэтому блокирование объекта аренды или одного из предметов имущест-

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

дящих в его коллекцию.

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

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

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

может быть применена и к концепции агрегата [15]. Следует, однако, быть осторожным,

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

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

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

объектами.

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

В данном примере воспользуемся моделью домена с супертипом слоя (Layer Super-

type, 491) и преобразователями данных (Data Mapper, 187). В качестве постоянного храни-

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

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

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

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

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

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

коллекция объектов (Identity Map, 216). Если блокируемые объекты совместно использу-

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

следнего. Поскольку класс version является частью модели домена, он совершенно не

подходит для размещения в нем кода работы с базой данных. Этот код лучше вынести в

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

table version.. .

create table version(id bigint primary key, value bigint,

modifiedBy varchar, modified datetime)

class Version...

private Long id;

private long value;

private String modifiedBy;

private Timestamp modified;

private boolean locked;

private boolean isNew;

private static final String UPDATE_SQL =

"UPDATE version SET VALUE = ?, modifiedBy = ?,

modified = ? " + "WHERE id = ? and value = ?";

private static final String DELETE_SQL = "DELETE

FROM version WHERE id = ? and value = ?";

private static final String INSERT_SQL =

"INSERT INTO version VALUES (?, ?, ?, ?)";

private static final String LOAD_SQL =

"SELECT id, value, modifiedBy, modified FROM

version WHERE id = ?";

public static Version find(Long id) {

Version version =

AppSessionManager.getSession().getldentityMap().

getVersion(id);

if (version == null) {

version = load(id);

}

return version;

}

private static Version load(Long id) {

ResultSet rs = null; Connection conn

= null; PreparedStatement pstmt =

null; Version version = null; try {

conn = ConnectionManager.INSTANCE.getConnection();

pstmt = conn.prepareStatement(LOAD_SQL);

pstmt.setLong(1, id.longValue()); rs =

pstmt.executeQuery(); if (rs.next ()) {

long value = rs.getLong (2); String

modifiedBy = rs.getString (3); Timestamp

modified = rs.getTimestamp(4); version = new

Version(id, value, modifiedBy,

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

modified);

AppSessionManager.getSession().getldentityMap().

putVersion(version); } else {

throw new ConcurrencyException("version " + id +

" not found.");

} } catch (SQLException

sqlEx) {

throw new SystemException("unexpected sql error loading

version", sqlEx); }

finally {

cleanupDBResources(rs, conn, pstmt);

}

return version; }

Класс version содержит метод для создания нового экземпляра объекта версии.

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

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

лен хотя бы один владелец указанного объекта версии. Каждый преобразователь данных

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

при вставке соответствующего объекта домена. Перед проведением вставки объект вер-

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

вставлена дважды.

class Version...

public static Version create () {

Version version = new Version (

IdGenerator.INSTANCE.nextld(), 0,

AppSessionManager.getSession() .getUser (), now());

version.isNew = true; return version; }

public void insert() {

if (isNewO) {

Connection conn = null;

PreparedStatement pstmt = null;

try {

conn = ConnectionManager.INSTANCE.getConnection ();

pstmt = conn.prepareStatement(INSERT_SQL);

pstmt.setLong(1, this.getld().longValue() ) ;

pstmt.setLong(2, this.getValue ()); pstmt.setString(3,

this.getModifiedBy()); pstmt.setTimestamp(4,

this.getModified()); pstmt.executeUpdate() ;

AppSessionManager.getSession().getldentityMap().

putVersion(this);

isNew = false; } catch

(SQLException sqlEx) {

throw new SystemException("unexpected sql error

inserting version", sqlEx);

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

} finally {

cleanupDBResources(conn, pstmt); } }

}

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

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

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

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

рован. После обращения к базе данных метод increment () проверяет, действительно ли

строка с номером версии была обновлена. Если количество измененных строк равно ну-

лю, метод increment () распознает нарушение параллелизма и выдает соответствующее

исключение.

class Version . . .

public void increment() throws ConcurrencyException { if

(!isLocked()) {

Connection conn = null;

PreparedStatement pstmt = null;

try {

conn = ConnectionManager.INSTANCE.getConnection ();

pstmt = conn.prepareStatement(UPDATE_SQL);

pstmt.setLong(1, value + 1);

pstmt.setString (2, getModifiedBy());

pstmt.setTimestamp(3, getModified());

pstmt.setLong(4, id.longValue() ) ;

pstmt.setLong(5, value);

int rowCount = pstmt.executeUpdate();

if (rowCount ==0) {

throwConcurrencyException(); }

value++; locked = true; } catch

(SQLException sqlEx) {

throw new SystemException("unexpected sql error

incrementing version", sqlEx); } finally {

cleanupDBResources(conn, pstmt); ) } )

private void throwConcurrencyException() {

Version currentVersion = load(this.getld());

throw new ConcurrencyException(

"version modified by " + currentVersion.modifiedBy

+ " at " + DateFormat. getDateTirnelnstance () .

format(currentVersion.getModified())); }