在使用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

總結

以上是生活随笔為你收集整理的使用ADF BC管理保存点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。