Для сеансов с поддержкой состояний ситуации, подобные описанным выше, как правило, приводят к удалению. Если Web-клиент, который создал объект сеанса, не может вернуться к работе с ним, то сеанс так или иначе должен быть удален, поскольку его никто уже не сможет использовать.
Для сеансов без поддержки состояний причины удаления более связаны с конкретными реализациями сервера EJB. Так, сервер может заметить, что группа сеансовых компонентов недогружена и что некоторым из компонентов требуется больший объем системных ресурсов. В этом случае группа сеансовых компонентов может быть сокращена.
Важно отметить, что удаление объекта сеанса невозможно, пока он используется клиентом. Удаление происходит только в состоянии пассивации или в незанятом состоянии объекта. Конечно, отказ сервера или другой серьезный сбой также приводят к удалению, но такой случай нежелателен.
Транзакции
Рассмотрим прецедент "Перевод денег", описанный в предыдущих главах. Этот прецедент сводится к снятию (дебетованию) суммы с одного счета и записи (кредитованию) такой же суммы на другой счет.
Проблема возникает, если в системе происходит сбой в момент, когда сумма снята с первого счета, но еще не записана на второй. Эта проблема связана с тем, что, вообще говоря, желательно, чтобы имели место либо обе операции, либо ни одна из них. Иными словами, операции снятия со счета и записи на счет тесно связаны друг с другом, и выполнять их следует как одну "единицу работы"3. Эта единица работы обычно называется деловой операцией или транзакцией.
Еще одной причиной введения транзакций является распределенный характер программного обеспечения уровня предприятия и необходимость не только свести к минимуму операции обработки исключительных ситуаций в клиенте, но и обеспечить их реализацию без излишнего написания кода на нескольких уровнях. Например, исключения не дают особенно много сведений о состоянии данной операции. Применение транзакций позволяет не полагаться на функции обработки особых ситуаций при определении последующих действий.
Как правило, транзакции, применяемые в системах, должны следовать принципам ACID (АСИД — атомарность, согласованность, изолированность, долговечность).
· Атомарность. Транзакции должны выполняться полностью или вообще не выполняться. Успешно завершенные транзакции фиксируются (данные обновляются), в противном случае происходит откат всей транзакции.
· Согласованность. Транзакции должны поддерживать систему в согласованном состоянии. Например, в прецеденте "Перевод денег", если транзакция по какой-то причине терпит сбой, система сохраняет согласованность, возвращаясь к состоянию до начала неудачной транзакции. Если транзакция завершается успешно, проверка согласованности устанавливает, изменились ли остатки на обоих счетах точно на переведенную сумму.
· Изолированность. Во время выполнения транзакции к данным, с которыми она работает, не должны обращаться или влиять на них другие процессы и транзакции, пока данная транзакция не завершится.
· Долговечность. Изменения, произведенные в результате транзакции, записываются в постоянное хранилище данных. Это позволяет восстанавливать систему после сбоя без потери результатов зафиксированных транзакций.
Принципы ACID— путеводная звезда при проектировании сеансовых компонентов. Правильно спроектированный компонент должен соответствовать требованиям ACID. В проекте сеансового компонента можно последовательно проверять, выполняется ли каждый из этих принципов.
Демаркация транзакции
Сеансовые компоненты прежде всего должны иметь "транзакционный" характер. Деловые методы, определенные в компоненте, выполняются либо как методы транзакции, либо как обычные, в зависимости от атрибутов, заданных в описателе развертывания компонента. Когда метод определен как метод транзакции, он должен вызываться с контекстом транзакции, который предоставляется клиентом, использующим данный сеанс, или самим контейнером EJB.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.