Статьи

Управление точками сохранения с ADF BC

При работе с 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 .