我做了一個應用程序來對網絡節點進行一些測試，比如ping測試，檢索磁盤空間等等。Batchlet vs EJB定時器
我使用一個計劃的小批量來運行的行動，但我不知道它是riglet使用的小部件？
EJB計時器應該更加相關嗎？另外，當我運行一個批處理程序時，我的glassfish服務器會保存批處理作業的日誌，我不需要它（特別是在一天內生成批量作業的情況下）。
如果我需要在相同的計劃時間內運行一些作業，我認爲批處理可以做到這一點，但EJB定時器呢？
你可以給我你的意見，以實現這一目的？當你的任務在眨眼（或左右）執行
感謝， Ersch
這不是一個明確答案的問題，但是將您的應用程序作爲一個批處理作業存在一定的代價，並且我會查看我得到的結果是否值得這樣做。
所以你正在考慮一個由單個Batchlet步驟組成的工作。那麼，從「重新啓動」功能中就不會有任何收穫，既不是在工作中失敗的步驟，也不是在塊步驟中利用檢查點。該小部件編程模型非常簡單...即使您真的很喜歡@BatchProperty，您現在也不得不處理XML。
如果您想要與其他批處理作業一起啓動，查看和管理這些執行情況，這隻會變得更有趣。這可能是因爲您正在使用提供某種實現特定附加功能的實現。這方面的一個例子可能是與外部調度程序軟件集成，允許按計劃安排作業。另一方面，如果您發現在一個地方（作業存儲庫，通常是持久數據庫）持續記錄所有批處理作業執行情況的價值，那麼這也可以爲您創造價值。
但是，如果你不關心任何這些，那麼EJB定時器可能是取而代之的方法。
使用EJB計時器是合適的。
否則使用批處理機制。
從EJB定時器執行的長時間運行任務可能會產生問題，因爲它們在短時間內正常超時的事務中執行。增加此事務超時也增加了數據庫和可能影響應用程序正常運行的其他資源鎖定的可能性。
雖然您不需要在事務中執行計時器任務。 –
如果作業已正確完成，我並不需要驗證或檢查。 我想要做的唯一事情就是查看一個節點是否還活着，如果它沒有活着，就在我的應用程序中生成一個警報。在磁盤空間檢查的情況下，如果達到可用空間觸發器，則創建一個alerte。 我在EJB中完成了功能的實現，但是在測試運行期間，我遇到了一些性能問題。 這就是爲什麼我希望在後臺有小塊的原因。因爲它是一個「學習的結束」工作，所以我需要儘可能多地通過錯誤來編寫代碼，希望它有助於確定我的需求。 – Ersch
似乎並不明顯，爲什麼該小程序可以避免計時器遇到的性能問題。好吧，祝你好運。 –
也許我對EJB的使用不好，我直接調用方法來檢查節點狀態以呈現我的jsf頁面，這樣在我的頁面凍結的方法運行期間。另外，可能會有一些批處理運行的時間，但我不知道我們是否可以通過EJB計時器來完成 – Ersch