的事務傳播

Question

現實生活中的場景有不同的事務傳播像

REQUIRED - 這是一個DML操作的情況。

SUPPORTS - 這是查詢數據庫的情況。

MANDATORY - ? 
REQUIRES_NEW - ? 
NOT_SUPPORTED - ? 
NEVER - ? 
NESTED - ? 

什麼是使用這些交易傳播的一些現實生活場景？爲什麼這些完全適合這種情況？

Answer 1

有各種各樣的用途並沒有簡單的答案，但我會努力成爲最explainatory

• 強制性的（預計交易）：當你想到的是什麼「高語境」通常用於層開始交易，你只想繼續。例如，如果你想要一個事務從HTTP請求到響應的整個操作。然後，您在JAX-RS資源級別開始事務處理，較低層（服務）需要事務在其內運行（否則引發異常）。
• REQUIRES_NEW（總是創建新的事務）：這將創建一個新的事務並掛起當前的事務（如果存在的話）。從上面的例子來看，這是您在JAX-RS資源上設置的級別。或者一般來說，如果你的流程以某種方式改變了，並且你想把你的邏輯分成多個事務（所以你的代碼有多個邏輯操作應該分開）。
• 要求（繼續交易或創建如果需要）：強制和REQUIRES_NEW之間的某種混合。在強制中，你期望交易存在，對於這個級別你希望它存在，如果不存在，你創建它。通常用於類似DAO的服務（根據我的經驗），但它確實取決於您的應用程序的邏輯。
• 支持（調用者決定是否在事務中運行）：如果您想使用與調用者相同的上下文（更高的上下文），如果調用者在事務中運行，那麼您也運行。如果沒有，你也是非交易型的。如果你想要更高的上下文來決定，也可以用在類似DAO的服務中。
• NESTED（子交易）：我必須承認我沒有在真實代碼中使用這一個，但通常您創建了一個真正的子交易，可以作爲某種檢查點。所以它運行在「父」事務的上下文中，但是如果失敗，它將返回到該檢查點（嵌套事務的開始）。當你在你的應用程序中需要這種邏輯時，這可能很有用，例如，如果你想向數據庫中插入大量的項目，提交有效的項目並跟蹤無效的項目（這樣你可以在嵌套事務失敗時捕獲異常，但是仍然可以承諾整個交易的有效期）
• 從來沒有（期待沒有交易）：這是你想要確保根本不存在交易的情況。如果在事務中運行的某些代碼達到此代碼，則會引發異常。所以通常這是與MANDARTORY完全相反的情況。例如。當你知道沒有交易應該受此代碼影響 - 很可能是因爲交易不應該存在。
• NOT_SUPPORTED（繼續非事務性地）：這比從不弱，你希望代碼以非事務方式運行。如果您以某種方式從交易所在的上下文中輸入此代碼，那麼您暫停該交易並繼續非交易。

根據我的經驗，你經常想要一個商業行爲是原子的。因此，每個請求只需要一個事務/ ...例如通過HTTP進行的簡單REST調用，它在一個類似HTTP的事務中執行一些數據庫操作。因此，對於注入此資源（或更低）的所有較低級別的服務，我的典型用法是頂級（JAX-RS資源）上的REQUIRES_NEW和強制。

這可能對您有幫助。它描述了具有

• REQUIRED給定傳播（呼叫者>方法）如何代碼的行爲：無 - > T1，T1-> T1
• REQUIRES_NEW：無 - > T1，T1-> T2
• 強制性：無 - >異常，T1-> T1
• NOT_SUPPORTED：無 - > NONE，T1-> NONE
• SU PPORTS：無 - > NONE，T1-> T1
• NEVER：無 - > NONE，T1->異常