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

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

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

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

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

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

чтения. Впрочем, обнаружить проблемы несогласованного чтения можно и с помощью

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

ческих проверок, например методов increment О или checkVersionlsLatest (). Ни-

же приведен пример единицы работы (Unit of Work, 205), содержащей проверку на согла-

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

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

class UnitOfWork...

private List reads = new ArrayList();

public void registerRead(DomainObject object) {

reads.add(object); }

public void commit() {

try {

checkConsistentReads();

insertNew();

deleteRemoved();

updateDirty();

} catch (ConcurrencyException e) {

rollbackSystemTransaction(); throw e; } }

public void checkConsistentReads() {

for (Iterator iterator = reads.iterator();

iterator.hasNext();) {

DomainObject dependent = (DomainObject)

iterator.next() ;

dependent.getVersion().increment(); } }

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

гда обнаруживает нарушение параллелизма (ConcurrencyException). Скорее всего, по-

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

могут возникнуть в процессе фиксации изменений. Не забывайте об этом шаге! Вместо

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

в интерфейс преобразователя.

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

Пессимистическая автономная блокировка (Pessimistic Offline Lock)

Двйвид Райе

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

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

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

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

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

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

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

как системы транзакций не приспособлены к работе с длинными транзакциями. Поэто-

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

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

тупом к данным.

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

(Optimistic Offline Lock, 434). Однако данное типовое решение имеет ряд недостатков.

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

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

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

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

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

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

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

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

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

конфликта самым радикальным способом — просто не допускает его. В пессимистиче-

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

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

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

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

Пессимистическая автономная блокировка реализуется в три этапа: определение необ-

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

применения блокировок. Кроме того, если пессимистическая автономная блокировка ис-

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

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

Первый возможный тип блокировки — это монопольная блокировка записи (exclusive

write lock), которая требует наложения блокировки только для редактирования данных.

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

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

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

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

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

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

чтения (exclusive read lock). В этом случае бизнес-транзакция накладывает блокировку на

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

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

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

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

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

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

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

записи. Она называется блокировкой чтения/записи (read/write lock) и имеет немного более

сложную схему, чем первые два типа. Данная схема подразумевает определенные отно-

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

• Блокировки чтения и записи являются взаимоисключающими. Строка базы дан

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

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

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

• Допускаются параллельные блокировки чтения. Наличие хотя бы одной блоки

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

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

вающих эту строку, вреда не принесет.

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

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

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

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

лову при моделировании системы.

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

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

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

системным аналитикам и проектировщикам предметной области. Блокировка — это не

только техническая проблема. Неправильный тип блокировки или блокирование непра-

вильных типов записей могут свести на нет эффективность всей пессимистической авто-

номной блокировки. Неэффективная стратегия блокировки не сможет сдержать натиск

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

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

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

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

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

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

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

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

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

нес-транзакция — это не вещь, которая может быть однозначно идентифицирована,

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

тем в вашем распоряжении почти наверняка окажется объект сеанса, поэтому концепцию

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

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

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

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

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

несколько ниже.

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

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

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

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

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

тельно воспользуйтесь типовым решением единственный элемент (Singleton) [20], которое

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

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

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

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

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

Вне зависимости от реализации (в виде объекта или SQL-оператора, применяемого

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

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

мим объектом блокировки.

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

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

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

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

в предоставлении блокировки будет отказано.

Вопрос "что блокировать?" зависит от вопроса "когда блокировать?", поэтому внача-

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

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

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

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

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

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

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

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

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

следующая проверка номера версии объекта по оптимистической схеме. Тем не менее

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

но предполагает наложение блокировки перед их загрузкой.

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

объекты (или нечто наподобие этого), однако на самом деле блокировка накладывается

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

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

ектов. Блокирование отдельных объектов хорошо всегда, когда не требует нарушать пра-

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

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

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

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

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

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

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

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

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

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

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

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

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

блокировок осуществлялся как можно раньше. Вообще говоря, по возможности все бло-

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

Доступ к каждому блокируемому элементу должен быть упорядочен. Если таблица

блокировки расположена в оперативной памяти, самый простой способ решения этой

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

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

обсуждаться не будут.

Если таблица блокировки расположена в базе данных, доступ к ней (первое правило!)

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

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

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

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

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

фикатор блокируемого элемента. Хранение в базе данных блокировок чтения/записи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Coarse-Grained Lock, 457).

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

ческие схемы блокирования системных транзакций наподобие оператора SELECT FOR

UPDATE или компонентов сущностей EJB предполагают ожидание до тех пор, пока бло-

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

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

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

сы А и Б. Если первый пользователь заблокирует ресурс А, а второй заблокирует ре-

сурс Б, обе транзакции будут бесконечно ожидать высвобождения второго ресурса. По-

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

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

транзакции может занять около 20 минут, а то и больше. Никто не захочет так долго

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

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

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

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

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

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

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

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

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

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

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

приложение, а сервер приложений. Для этого серверы Web-приложений применяют

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

ции объекта, который автоматически высвобождает все блокировки, когда НТТР-

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

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

больше определенного значения.

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в числе которых можно назвать SQL-оператор SELECT FOR UPDATE (ДЛЯ баз данных) и

компоненты сущностей EJB (для серверов приложений). Зачем же утруждать себя подбо-

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

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

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

тите внимание на то, что противоположное утверждение в корне неверно! Материал, из-

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

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

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

управления транзакциями.

Пример: простой диспетчер блокировки (Java)

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

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

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

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

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

interface ExclusiveReadLockManager...

public static final ExclusiveReadLockManager INSTANCE =

(ExclusiveReadLockManager) Plugins.getPlugin(

ExclusiveReadLockManager.class);

public void acquireLock(Long lockable, String owner) throws

ConcurrencyException;

public void releaseLock(Long lockable, String owner);

public void relaseAHLocks (String owner);

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

Обратите внимание, что параметр lockable ("блокируемый элемент") имеет тип

Long, а параметр owner ("владелец") — тип string. Это сделано по двум причинам. Во-

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

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

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

тываемых таблицей блокировки). Во-вторых, мы рассматриваем Web-приложение, а по-

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

сеанса, являющийся строкой.

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

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

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

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

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

блокировки — удалению соответствующей строки. Ниже приведена схема таблицы lock

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

table lock...

create table lock(lockableid bigint primary key,

ownerid bigint)

class ExclusiveReadLockManagerDBImpl implements

ExclusiveLockManager...

private static final String INSERT_SQL =

"insert into lock values(?, ?)";

private static final String DELETE_SINGLE_SQL = "delete

from lock where lockableid = ? and ownerid = ?";

private static final String DELETE_ALL_SQL =

"delete from lock where ownerid = ?";

private static final String CHECK_SQL = "select lockableid

from lock where lockableid = ? and ownerid = ?";

public void acquireLock(Long lockable, String owner) throws

ConcurrencyException {

if (IhasLock(lockable, owner)) {

Connection conn = null;

PreparedStatement pstmt = null;

try {

conn = ConnectionManager.INSTANCE.getConnection();

pstmt = conn.prepareStatement(INSERT_SQL);

pstmt.setLong(1, lockable.longValue() ) ;

pstmt.setString(2, owner); pstmt.executeUpdate (); }

catch (SQLException sqlEx) {

throw new ConcurrencyException("unable to lock " +

lockable);

} finally (

closeDBResources(conn, pstmt); } } )

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

public void releaseLock(Long lockable, String owner) {

Connection conn = null; PreparedStatement pstmt =

null; try {

conn = ConnectionManager.INSTANCE.getConnection ();

pstmt = conn.prepareStatement(DELETE_SINGLE_SQL);

pstmt.setLong(1, lockable.longValue());

pstmt.setString(2, owner);

pstmt.executeUpdate(); }

catch (SQLException sqlEx) {

throw new SystemException("unexpected error releasing lock on

" + lockable); } finally {

closeDBResources(conn, pstmt); } }

В приведенном фрагменте кода не показана реализация открытого метода ге-

leaseAHLocks () И закрытого метода hasLockf). Суть метода releaseAHLocks ()

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

дельца. Метод hasLock () обращается к базе данных с запросом о том, не существует ли у

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

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

вставкой в таблицу блокировки новой строки метод acquireLock () должен обратиться

к таблице и посмотреть, нет ли в ней этой же блокировки. Поскольку таблица блокиров-

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

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

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

уровне сеанса. Будьте очень внимательны, кэшируя блокировки!

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

записи о покупателях. Вначале создадим некоторое подобие инфраструктуры для обра-

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

дим объект пользовательского сеанса, поэтому одного лишь HTTP-сеанса будет недоста-

точно. Чтобы отличить новый объект сеанса от HTTP-сеанса, назовем его сеансом при-

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

вателя и коллекцию объектов (Identity Map, 216) для кэширования объектов, загруженных

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

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

class AppSession...

private String user;

private String id;

private IdentityMap imap;

public AppSession (String user, String id, IdentityMap imap) {

this.user = user;

this.imap = imap;

this.id = id;

}

class AppSessionManager...

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

private static ThreadLocal current = new ThreadLocal();

public static AppSession getSession() {

return (AppSession) current.get(); } public static

void setSession(AppSession session) {

current.set(session); }

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

(Front Controller, 362), поэтому нам понадобится определить объект команды. Первое,

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

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

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

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

транзакций.

interface Command...

public void init(HttpServletRequest req, HttpServletResponse rsp)

; public void pracesst) throws Exception;

abstract class BusinessTransactionCommand implements Command...

public void init(HttpServletRequest req, HttpServletResponse

rsp) {

this.req = req; this.rsp = rsp; } protected

void startNewBusinessTransaction() {

HttpSession httpSession = getReq().getSession(true);

AppSession appSession = (AppSession)

httpSession.getAttribute(APP_SESSION); if (appSession !=

null) {

ExclusiveReadLockManager . INSTANCE . relaseAHLocks (

appSession.getld() ) ;

}

appSession = new AppSession(getReq().getRemoteUser(),

httpSession.getld(), new IdentityMap());

AppSessionManager.setSession(appSession);

httpSession.setAttribute(APP_SESSION, appSession);

httpSession.setAttribute(LOCK_REMOVER, new

LockRemover(appSession.getld()));

}

protected void continueBusinessTransaction() {

HttpSession httpSession = getReq().getSession();

AppSession appSession = (AppSession)

httpSession.getAttribute(APP_SESSION) ;

AppSessionManager.setSession(appSession);

}

protected HttpServletRequest getReq() {

return req;