Java EE：引發@ApplicationException，仍然回滾事務

我需要一些指導，以便如何在Java EE環境中最佳使用異常，並通過JAX-RS爲客戶端提供服務。Java EE：引發@ApplicationException，仍然回滾事務

目前，我有一些例外，全部延伸RuntimeException，並註明@ApplicationException(rollback=false)。爲了將它們傳送給客戶，它們帶有一個JAXB註釋的實體;並且ExceptionMapper已準備好將它們轉換爲正確，有意義的HTTP響應（包括HTTP狀態碼）。

我沒有任何關於交易行爲的規定，所以我想它默認爲CMT。

好東西到目前爲止：當服務器決定，它不能滿足一個請求，因爲輸入數據是無效的/足夠的/無論什麼，它會拋出我的一個BadRequestException，這使得它的JAX-RS資源，它被映射到HTTP響應。客戶被告知出了什麼問題。

問題我的是我總是得到javax.ejb.TransactionRolledbackLocalException，由BadRequestException造成！我不希望交易回滾！ @ApplicationException似乎被忽略...

我不應該從RuntimeException延伸，而是使用檢查的異常嗎？我雖然@ApplicationException應該是正確的方式...

有關背景信息：我的所有異常將容器/ bean留在工作狀態。不需要銷燬bean實例或者類似的東西。

來源

2011-06-08 Hank

好的，原來看手冊確實幫助有時:)。

an @ApplicationException根據定義而不是 a RuntimeException。事實上，投擲RuntimeExceptions似乎是一個非常糟糕的主意，那就是要拆掉一個bean實例，回滾事務等

切換後，一切都將基於檢查異常，我的代碼不僅看起來更更好的是，IDE支持我也好多了。它就像一個魅力。現在我可以控制，如果我的ApplicationException應該導致事務回滾或不。

我發現this link有用，儘管它描述了Bea Weblogic。

來源

2011-06-08 16:34:42 Hank

EJB 3.1規範，第14.2.1節：「應用程序異常是未經檢查的異常通過與ApplicationException的元數據註釋來註釋，或表示它定義爲一個應用程序異常在具有application-exception元素的部署描述符中。「 – 2011-06-09 13:02:17

謝謝。奇怪的是，Glassfish 3.1不遵循規範。 – Hank 2011-06-14 13:36:54

這個答案不正確，並且包含錯誤信息。從bick引用的EJB規範中再引用一段更長的引用：「被檢查異常的應用程序異常可以通過在bean的businessinterface，無界面視圖，home界面，組件界面等的方法的throws子句中列出來定義。和web服務端點，應用程序異常是一個未經檢查的異常，通過使用ApplicationException元數據註釋對其進行註釋，將其定義爲應用程序異常。 – eis 2014-02-11 15:53:51

對於處理同樣問題的其他人：當Exception類不包含在ejb-jar中時，將忽略Annotation @ApplicationException（未掃描/未處理）。當我們的ApplicationException是API jar的一部分時，這是一個常見的情況。在這種情況下，我們必須使用XML描述符來標記ApplicationException。

看這裏幫我 - >https://www.java.net//node/665096

來源

2013-07-18 11:00:27 woczkowski

這非常有幫助。你可能想知道這是一個在GF3中修復的bug：https://java.net/jira/browse/GLASSFISH-5183 – 2014-03-06 21:07:58

我遇到了與wildfly 10.0 Final相同的問題。當異常處於不同的應用程序和不同的EJB中時，異常不會導致回滾（提交）。當我移動它時，它工作得很好。 – fallens4e 2018-01-18 08:06:07

Java EE：引發@ApplicationException，仍然回滾事務

回答

相關問題