我試圖決定是否在我的應用程序中使用java-ee計時器。我正在使用的服務器是Weblogic 10.3.2EJB計時器性能
需求如下：從EJB調用異步Web服務一小時後，如果未調用異步回調方法，則需要執行一些操作。關於回調方法是否已被調用以及執行調用日期的信息存儲在數據庫中。
兩種可能我看到的是：
從純粹的編程角度來看，它看起來更容易，更清潔，但是我擔心我可能會遇到的性能問題，如果假設在一個時刻創建了100.000個Timer。
有什麼想法？
你會更好地有一個更專業的過程。真正的問題是100,000問題。這取決於你的行動需要多長時間。
因爲它很容易看到每一秒，在EJB計時器會火起來的30個線程來處理目前所有的待處理作業的，因爲這是它如何工作的。
而且計時器是持久的，所以你的EJB管理計時器表將被保存和刪除每秒（60個）30行，這是假設交易100K /小時。
所以，這是非常迅速發生的大量工作。我可以很容易地看到這個系統只是「落後」而且從不追趕。
一個專門的進程將是重量輕得多，也許可以批量行動電話（撥打每個線程5個行動，而不是每線程），等等。這將是很好，如果你沒有堅持計時器事件，但事實就是如此。您幾乎可以輕鬆地簡單地將計時器事件追加到文件以保證安全，並將其保存在內存中。在系統重新啓動時，您可以重新加載該文件，然後滾動文件（每小時創建一個新文件，在舊文件全部耗盡後刪除舊文件等）。這將節省大量的數據庫流量，但是可能會失去數據庫的事務性質。
無論如何，我不認爲你希望使用EJB計時器對於這一點，我不認爲它真的爲此設計的交通量。但你可以隨時測試並看到。確保你測試重啓你的容器，看看它有多好的工作，在它的表中有100K掛起計時器作業。
全部取決於容器使用的內容。例如JBoss使用Quartz Scheduler來實現EJB定時器功能。當你有大約100 000個計時器實例時，石英是相當不錯的。
也許你可以使用其中的一些想法：
我在哪裏，我們已經構建了一個類似cron的調度器，它由一個定時器驅動。當定時器觸發時，系統使用Quartz CronTrigger檢查哪些cron需要運行。通常這些cron有很多工作要做，我們處理的方式是每個cron將其個別任務作爲JMS消息轉換，然後由MDB處理這些消息。目前這個運行在單一的Glassfish的實例，併爲我們的任務負荷的增加，我們應該能有一個集羣，多個節點正在處理的JMS消息擴大這件事。我們通過設置與GlassFish ejb-jar.xml中最大池大小（也稱爲太陽ejb-jar.xml中）平衡每種類型的任務的JMS消息的處理負荷。
建立這樣一個制度，讓所有的細節權是不平凡的，但它證明確實有效。
@Pau：爲什麼ü需要創建一個由每次通話計時器...代替ü可以在啓動時應用其中每半小時運行後創建一個計時器線程（可配置）的時間和外觀期數據庫中的所有Web服務調用，其響應尚未收到，其要求的時間是過去的1小時。對於選定的記錄，在for循環中，它可以執行所需的操作。如果你要進行一次重要活動
遠高於設計可能沒有用處。
如果您在應用程序具有彈性的框架，你也可以查找它的定時器services.http：//static.springsource.org/spring/docs/1.2.9/reference/scheduling.html
我使用weblogic。 – Pau