При работе с ADF BC мы обычно полагаемся на среду для выполнения операций DML в базе данных. Каркас правильно делает все необходимые обновления в базе данных во время цикла фиксации DBTransaction. Круто то, что транзакция с базой данных будет осуществляться автоматически в этом случае. Таким образом, если что-то пошло не так, если некоторым объектам не удалось выполнить публикацию в базе данных, платформа собирается откатить текущую транзакцию до точки сохранения в самом начале процесса фиксации. Кроме того, состояние корневого прикладного модуля также будет восстановлено до той же точки. Фреймворк делает все это за нас, и нам не нужно заботиться об этом.
Тем не менее, существует очень распространенный вариант использования, когда необходимо выполнить некоторый DML в базе данных для реализации какого-либо метода бизнес-службы. Давайте рассмотрим метод в классе реализации AM:
1
2
3
4
5
6
|
public void someBusinessMethod() { invokePLSQLProcedure1(); modifySomeAttributes(); invokePLSQLProcedure2(); getDBTransaction().commit(); } |
Этот метод вызывает процедуру PL / SQL, изменяя некоторые данные в базе данных, изменяет некоторые атрибуты в кэше сущностей, вызывает другую процедуру PL / SQL и выполняет фиксацию. Представьте себе, что происходит, если второй вызов процедуры PL / SQL не удался или если по какой-то причине среда не смогла зафиксировать транзакцию. Очевидно, что в базе данных есть блокировка, так как транзакция не зафиксирована и не откатана. Кроме того, кэш сущностей содержит данные, измененные методом modifySomeAttributes (), несмотря на то, что произошел сбой someBusinessMethod . Чтобы предотвратить все эти плохие вещи, мы должны управлять этой транзакцией вручную. Давайте в классе реализации AM пара полезных методов:
01
02
03
04
05
06
07
08
09
10
11
12
|
//Passivates the AM's state in the passivation storage private String passivateStateForUndo() { String savePoint = super .passivateStateForUndo( null , null , PASSIVATE_UNDO_FLAG); return savePoint; } //Rollbacks the transaction and restores the AM's state private void activateStateForUndo(String savePointId) { super .activateStateForUndo(savePointId, ACTIVATE_UNDO_FLAG); } |
Давайте использовать эти вспомогательные методы в методе someBusinessMethod () :
01
02
03
04
05
06
07
08
09
10
11
12
|
public void someBusinessMethod() { String spid = passivateStateForUndo(); try { invokePLSQLProcedure1(); modifySomeAttributes(); invokePLSQLProcedure2(); getDBTransaction().commit(); } catch (RuntimeException e) { activateStateForUndo(spid); throw new JboException(e); } } |
Обратите внимание, что методы passivateStateForUndo и activStateForUndo работают с точками сохранения только с точки зрения управления состоянием AM и в действительности не работают с точками сохранения транзакций в базе данных. Метод activStateForUndo выполняет реальный откат в базе данных, но состояние AM (включая грязный кэш сущностей) будет восстановлено в тот момент, когда снимок был сделан методом passivateStateForUndo .
Это оно!
Ссылка: | Управление точками сохранения с ADF BC от нашего партнера JCG Евгения Федоренко в блоге ADF Practice . |