付款交易與數據庫交易

Question

因此，在付款處理中，您具有付款交易的概念。 由於付款或消息來自各種內部和外部接口，因此可能在某些關系數據庫的某些主基礎交易表中創建了付款交易（至少出於這個問題的緣故）。 然后，交易具有一些狀態，這些狀態會通過一系列編輯更改，直到達到幾個最終狀態（已付款或未付款，已批准或已拒絕等）之一。

在處理數據庫時，您當然擁有數據庫事務，而我的問題是， 在數據庫事務中處理付款事務是否有任何經驗法則？ 交易通常是許多其他表的匯總根，以獲取有關參與該交易的客戶或持卡人或商戶或速度設置的信息。

我可以看到一條規則，說“在數據庫事務中永遠不要處理多個付款事務”。 但是在執行批處理類型操作時，當您必須考慮整個事務批處理成功或失敗時，我也可以看到數據庫事務是正確的，因此您可以選擇回滾。

Answer 1

正常的設計模式是遵循以下規則：使用數據庫事務將數據庫從一種有效狀態轉換為另一種有效狀態。

在支付交易的上下文中，這可能意味着添加交易是一個數據庫交易。 然后，事務上的每個處理步驟（例如驗證，履行等）將是另一個數據庫事務。

我可以看到一條規則，說：“在數據庫事務中，永遠不要處理多個付款事務”

出於性能或架構方面的考慮，您可以將多個邏輯事務放入一個物理事務中。 那不一定是問題。 但是，您需要確保工作不會丟失，因為失敗將中止整個批次。