java.util.Timer中VS EJB TimerBean

我要實現對以下情形簡單的計時器任務 -java.util.Timer中VS EJB TimerBean

method1(){ 
..... 
    if(success){ 
     trigger method2 for next 30 min every 15 sec 
    } 
}

我已經實現了使用java.util.Timer中和java.util.TimerTask中，其工作的代碼精細。但是，我的代碼最終將作爲glassfish服務器中的Web服務進行部署。所以我想知道它會因爲glassfish容器而產生任何問題，因爲我通過Timer間接使用線程。

我也不確定我是否應該EJB定時器Bean。有人可以請告知這兩種方法的優缺點嗎？

來源

2013-01-22 csn

與大多數EJB一樣，兩種技術最大的區別就是事務處理。定時器EJB就是EJB，因此每個調用都將是一個唯一的事務，容器將爲您管理所有這些細節。

線程（特別是如果從EJB中創建的話）將具有未確定的事務狀態。大多數容器將很多上下文與當前正在執行的線程相關聯，尤其是事務性狀態，這是自制線程在EJB容器中是壞主意的一個原因 - 容器上下文信息可能丟失或損壞。

對於EJB定時器，您可以輕鬆創建一個每隔15秒觸發一個的定時器，但您需要在30分鐘後手動跟蹤並取消它。你可以使用ScheduleExpression來表達「每15米爲30米」的規則，但你仍然需要在最後取消計時器（並且坦率地說，更多的工作可以正確地創建該表達式）。只需在Timers Info中放入一個開始時間，告訴它什麼時候開始，然後它就可以在最後一次運行時自行終止。在Java EE 6之前的日子裏，定時器是持久的，並且在容器重新啓動後仍然存活（儘管不重新部署應用程序）。現在，持久性是可選的，所以你需要注意那個細節。

如果此方法是從Web層（而不是EJB層）觸發的，則可以放寬線程限制，也可以使用Quartz Timer。

但是EJB定時器非常好，對於Java EE 6更好。我會使用EJB定時器，但我對它們很滿意，並且已經使用了難以使用的Java EE 6之前的版本一段時間。如果你在這個整個過程的EJB層中，我一定會使用它們。

來源

2013-01-22 05:11:23

EJB規範警告用戶編碼（或第三個側面編碼）線程。

企業bean不能嘗試管理線程。企業bean不得嘗試啓動，停止，掛起或恢復線程，或者更改線程的優先級或名稱。企業bean不能嘗試管理線程組。（21.2.2編程限制，EJB 3.1規範）

EJB定時器Bean是首選。

來源

2013-01-22 04:48:26

對於複雜的要求，Quartz也是首選。 –

java.util.Timer中VS EJB TimerBean

回答

相關問題