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

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

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

Оптимистическая автономная блокировка (Optimistic Offline Lock)

Дейвид Райе

Предотвращает возникновение конфликтов между параллельными

бизнес-транзакциями путем обнаружения конфликта и отката

транзакции

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

Довольно часто выполнение бизнес-транзакции охватывает несколько системных

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

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

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

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

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

сованностью чтения.

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

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

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

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

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

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

данных.

В отличие от пессимистической автономной блокировки (Pessimistic Offline Lock, 445),

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

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

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

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

телей.

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

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

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

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

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

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

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

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

писи, изменяемой во время системной транзакции.

Наиболее распространенный прием отслеживания изменений — сохранение вместе с

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

сохраняться вместе с остальными элементами состояния сеанса. Наложение оптимисти-

ческой автономной блокировки состоит в сравнении номера версии, хранящегося в со-

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

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

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

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

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

В реляционных СУБД реализация описанного приема требует проверки номера вер-

сии в любом SQL-операторе, применяемом для обновления или удаления записи. Один

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

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

нения SQL-оператора. Если количество измененных строк равно 1, это означает, что об-

новление прошло успешно. Если же количество измененных строк равно 0, следователь-

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

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

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

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

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

новление еще раз (рис. 16.1).

Для разрешения конфликтов, возникающих при параллельной обработке данных,

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

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

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

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

меткой — системные часы слишком ненадежны, особенно если речь идет о координации

работы нескольких пользователей.

Вместо сравнения номера версии в выражении WHERE оператора UPDATE МОЖНО ВЫ-

ПОЛНИТЬ сравнение по всем полям текущей строки, что позволяет обойтись без специаль-

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

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

пулирования потенциально большими выражениями WHERE, ЧТО может негативно ска-

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

ло СУБД использует индекс по первичному ключу).

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

веркой номера версии в каждом операторе UPDATE ИЛИ DELETE. К сожалению, это не ре-

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

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

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

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

. Что произойдет, если в это же время другой

сеанс, относящийся к службе работы с клиентами, изменит адрес покупателя? Так как

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В США величина налога с продажи зависит от штата, а иногда и от города, в котором живет покупа-

тель. — Прим. пер.

Рис. 16.1. Проверка номера версии при оптимистическом блокировании с помощью оператора UPDA ТЕ

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

Для некоторых проблем несогласованного чтения проверка номера версии может

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

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

из ее полей. В этом случае для повышения степени параллелизма системы вместо про-

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

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

транзакций. Чем лучше вы понимаете проблемы параллельной обработки данных кон-

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

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

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

ривает группу объектов как единый блокируемый элемент. Еще одной возможной аль-

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

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

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

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

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

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

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

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

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

ред фиксацией изменений.

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

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

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

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

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

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

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

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

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

Теперь представьте себе обновление коллекции: как следует поступить, если два сеанса

одновременно добавят в коллекцию новый элемент? Обычная схема оптимистической ав-

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

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

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

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

дом (source code management — SCM). Когда такая система обнаруживает конфликт меж-

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

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

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

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

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

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

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

обычно требуется не одна, а сотни стратегий слияния. Некоторые из этих стратегий

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

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

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

зации любыми возможными и невозможными способами. Хотя на практике слияние

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

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

решений. Я больше не буду углубляться в эту тему, однако еще раз обращаю ваше внима-

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

оптимистической автономной блокировки.

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

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

закции. Между тем иногда о возникновении конфликта хотелось бы узнавать порань-

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

ли обновляемые данные изменены кем-то другим. Конечно, этот метод не гарантирует

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

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

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

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример: слой домена с преобразователями данных (Java)

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

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

щим номер версии, и операторов UPDATE И DELETE, использующих номер версии как

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

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

автономной блокировки с использованием модели предметной области (Domain Model, 140)

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

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

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

блокировки.

Вначале следует убедиться, что супертип слоя (Layer Supertype, 491) предметной облас-

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

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

менение, и номере версии.

class DomainObject...

private Timestamp modified;

private String modifiedBy;

private int version;

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

должна содержать в себе эти сведения. Ниже приведена схема таблицы customer, а так-

же реализация стандартного набора SQL-операций CRUD (Create Read Update Delete —

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

автономной блокировки.

table customer...

create table customer(id bigint primary key, name varchar,

createdby varchar, created datetime, modifiedby varchar,

modified datetime, version int)

SQL customer CRUD...

INSERT INTO customer VALUES (?, ?, ?, ?, ?, ?, ?)

SELECT * FROM customer WHERE id = ?

UPDATE customer SET name = ?, modifiedBy = ?, modified = ?,

version = ? WHERE id = ? and version = ?

DELETE FROM customer WHERE id = ? and version = ?

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

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

ряющиеся фрагменты объектно-реляционного отображения. Это не только сократит

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

ную блокировку (Implicit Lock, 468) для нейтрализации наиболее рассеянных разработчи-

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

шить весь механизм блокирования.

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

строение SQL-выражений. Для реализации подобной схемы преобразователям пона-

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

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

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

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

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

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

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

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

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

данных столбцов.

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

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

class AbstractMapper...

public AbstractMapper(String table, String[] columns) {

this.table = table; this.columns = columns;

buildStatements(); }

public DomainObject find(Long id) {

DomainObject obj =

AppSessionManager.getSession().getldentityMap()-get(

id);

if (obj == null) {

Connection conn = null;

PreparedStatement stmt = null;

ResultSet rs = null; try {

conn = ConnectionManager.INSTANCE.getConnection();

stmt = conn.prepareStatement(loadSQL);

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

stmt.executeQuery(); if (rs.nextO) {

obj = load(id, rs); String modifiedBy =

rs.getString( columns.length + 2);

Timestamp modified = rs.getTimestamp(

columns.length + 3);

int version = rs.getlnt(columns.length + 4);

obj.setSystemFields(modified, modifiedBy,

Aversion) ;

AppSessionManager.getSession().getldentityMap().

put(obj);

} else {

throw new SystemException(table + " " + id +

" does not exist");

} } catch (SQLException sglEx)

(

throw new SystemException("unexpected error finding "

+ table + " " + id); } finally {

cleanupDBResources(rs, conn, stmt); } )

return obj;

}

protected abstract DomainObject load(Long id, ResultSet rs)

throws SQLException;

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

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

тов (Identity Map, 216), чтобы убедиться, что искомый объект еще не был загружен. Не-

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

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

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

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

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

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

ний соответствующих полей и возвращения активизированного объекта. По завершении

этой операции преобразователь вызывает метод setSystemFields (), чтобы установить

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

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

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

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

Приведем реализацию метода load () в конкретном классе преобразователя.

class CustomerMapper extends AbstractMapper...

protected DomainObject load(Long id, ResultSet rs)

throws SQLException (

String name = rs.getString(2);

return Customer.activate(id, name, addresses);

}

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

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

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

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

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

рировать исключение ConcurrencyException. Как выглядит операция удаления, пока-

зано ниже.

class class AbstractMapper...

public void delete(DomainObject object) {

AppSessionManager.getSession().getldentityMap().remove(

object.getld() ) ;

Connection conn = null;

PreparedStatement stmt = null; try

{

conn = ConnectionManager.INSTANCE.getConnection();

stmt = conn.prepareStatement(deleteSQL);

stmt.setLong (1, object.getld () .longValue());

int rowCount = stmt.executeUpdate();

if (rowCount == 0) {

throwConcurrencyException(object);

} } catch (SQLException

e) {

throw new SystemException("unexpected error deleting");

} finally {

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

cleanupDBResources (conn, stmt); } }

protected void throwConcurrencyException(DomainObject object)

throws SQLException {

Connection conn = null;

PreparedStatement stmt = null;

ResultSet rs = null; try {

conn = ConnectionManager.INSTANCE.getConnection();

stmt = conn.prepareStatement(checkVersionSQL);

stmt.setlnt (1, (int) object.getld().longValue());

rs = stmt.executeQuery(); if (rs.nextO) {

int version = rs.getlnt (1); String

modifiedBy = rs.getString(2); Timestamp

modified = rs.getTimestamp(3); if (version

> object.getVersion()) {

String when = DateFormat.getDateTimelnstance().

format(modified);

throw new ConcurrencyException(table + " " +

object.getld() + " modified by " + modifiedBy + " at " + when);

} else {

throw new SystemException("unexpected error

checking timestamp");

} )

else {

throw new ConcurrencyException(table + " " +

object.getld() + " has been deleted");

} }

finally {

cleanupDBResources(rs, conn, stmt); } }

SQL-оператор, применяемый ДЛЯ Проверки номера версии В методе throwConcur-

rencyException, должен быть известен и абстрактному преобразователю. Последний

будет конструировать его вместе с выражениями CRUD. Данное выражение выглядит

примерно так, как показано ниже.

checkVersionSQL...

SELECT version, modifiedBy, modified FROM customer

WHERE id = ?

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

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

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

осуществляться в рамках той же системной транзакции, что и сама фиксация изменений.

В нашем примере проверка номера версии вставлена в операторы UPDATE ИЛИ DELETE,

поэтому данное условие выполняется автоматически.