在使用ADF BC时，我们通常依赖于在数据库中执行DML操作的框架。 在DBTransaction提交周期内，该框架正确地在数据库中进行了所有必要的更新。 很酷的事情是，在这种情况下，数据库事务将被自动管理。 因此，如果出现问题，如果某些实体无法发布到数据库，则框架将在提交过程的最开始将当前事务回滚到保存点。 此外，根应用程序模块的状态也将还原到同一点。 该框架为我们完成了所有这些工作，我们不需要关心它。

但是，当需要在数据库中执行一些DML以实现某些业务服务方法时，存在一个非常常见的用例。 让我们考虑AM实现类中的方法：

public void someBusinessMethod() {invokePLSQLProcedure1();modifySomeAttributes();invokePLSQLProcedure2();       getDBTransaction().commit();
}

该方法调用PL / SQL过程，修改数据库中的某些数据，修改实体缓存中的某些属性，调用另一个PL / SQL过程并执行提交。 想象一下，如果第二个PL / SQL过程调用失败，或者由于某种原因框架未能提交事务，将会发生什么。 显然，数据库中有一个锁，因为事务既不提交也不回滚。 此外，尽管someBusinessMethod失败，实体缓存仍包含由ModifySomeAttributes（）方法修改的数据。 为了防止所有这些不好的事情，我们必须手动管理此事务。 让我们在AM实现类中有几个实用程序方法：

//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（）方法中使用这些辅助方法：

public void someBusinessMethod() {String spid = passivateStateForUndo();try {           invokePLSQLProcedure1();            modifySomeAttributes();           invokePLSQLProcedure2();       getDBTransaction().commit();               } catch (RuntimeException e) {activateStateForUndo(spid);throw new JboException(e);}}

请注意， passivateStateForUndo和activateStateForUndo方法仅在AM状态管理方面与保存点一起使用，而实际上与数据库中的事务保存点无关。 activateStateForUndo方法会在数据库中执行真正的回滚 ，但是直到通过passivateStateForUndo方法拍摄快照时，AM状态（包括脏实体缓存）都将被还原。

而已！

翻译自: https://www.javacodegeeks.com/2015/01/managing-savepoints-with-adf-bc.html