Spring事務REQUIRED與REQUIRES_NEW：回滾事務

Question

我有一個具有propagation = Propagation.REQUIRES_NEW事務屬性的方法：

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void createUser(final UserBean userBean) {
    //Some logic here that requires modification in DB
}

---

此方法可以同時調用多次，並且對於每個事務，如果發生錯誤而不是回滾（獨立於其他事務）。

問題是，這可能會迫使Spring創建多個事務，即使另一個事務可用，也可能導致一些性能問題。

---

Java doc of propagation = Propagation.REQUIRED說： Support a current transaction, create a new one if none exists.

這似乎解決了性能問題，不是嗎？

回滾問題怎么樣？ 如果新方法調用在使用現有事務時回滾，該怎么辦？ 即使以前的電話會不會回滾整個交易？

[編輯]我想我的問題不夠明確：

我們有數百個客戶端連接到我們的服務器。

對於每個客戶端，我們自然需要發送有關事務的反饋（OK或exception - > rollback）。

我的問題是：如果我使用REQUIRED ，它是否意味着只使用了一個事務，如果第100個客戶端遇到問題，第一個客戶端的事務也將回滾？

Answer 1

使用REQUIRES_NEW僅在從事務上下文調用方法時才有意義; 當從非事務性上下文調用該方法時，它的行為與REQUIRED完全相同 - 它將創建一個新事務。

這並不意味着所有客戶端只會有一個單一事務 - 每個客戶端都將從非事務性上下文開始，一旦請求處理將命中@Transactional ，它將創建一個新事務。

因此，考慮到這一點，如果使用REQUIRES_NEW對該操作的語義有意義 - 我不會擔心性能 - 這會使教科書過早優化 - 我寧願強調正確性和數據完整性，並且一旦性能指標有性能就會擔心性能已被收集，而不是之前。

在回滾時 - 使用REQUIRES_NEW將強制啟動新事務，因此異常將回滾該事務。 如果還有另一個正在執行的事務 - 根據操作的具體情況，將根據異常是否在堆棧中冒泡或被捕獲而將會回滾或不回滾 - 這是您的選擇。 此外，為了更深入地討論交易策略和回滾，我建議： «交易策略：了解交易陷阱»，Mark Richards 。

Answer 2

如果您確實需要在單獨的事務中執行此操作，則需要使用REQUIRES_NEW並使用性能開銷。 注意死鎖。

我寧願那樣做：

• 驗證Java端的數據。
• 在一個事務中運行每個事務。
• 如果DB端出現任何問題 - >這是DB或驗證設計的一個重大錯誤。 回滾所有內容並拋出關鍵的頂級錯誤。
• 寫出好的單元測試。