針對Java EE的長事務時間解決方案？

Question

我在職業生涯中遇到過的一個問題是在分層服務體系結構中，如果一個下游系統進入一個狀態，並且它的所有線程都在死鎖或某種類型的該系統中的無限循環錯誤。在這些情況下，Java EE服務器上的服務器套接字仍在接受和排隊來自客戶端應用程序的請求。這會導致客戶端應用程序使用其所有線程等待來自正確建立的套接字連接的響應。然後，所有用戶都被鎖定在系統外面，因爲他們的請求也在排隊。

我想過一些解決方案，但我想知道社區是否有一些更好的解決方案。

1. 下游請求的隔離線程池。這會成爲一個問題，因爲您在系統中混合了空閒線程的數量，從而創建許多需要足夠線程以確保完整吞吐量的小型池。產卵線程意味着你需要自己處理事務和安全上下文。不是真正的受支持的Java EE解決方案。

2. MDB解決方案是Java EE的首選異步解決方案，但這看起來相當重量級，但具有讓應用服務器處理管理MDB線程池的額外好處。 （目前排在我名單上的第一位）

3. ESB。這是更重的，並增加了更多的網絡和處理時間。但它允許您設置單個服務超時。還有一個問題，它將需要永遠在一個大公司實施，所以可能不適合我的時間框架。

你們有什麼好點子嗎？

Answer 1

你是正確的，因爲MDB的情況是正常的解決方案，它通常也支持超時，這將有助於避免掛起請求。話雖如此，它可能不會真正解決問題，但只需將備份轉移到JMS隊列，而不會將響應發回客戶端。當然，如果只有一個服務導致這個問題，其他服務現在仍然可以訪問。

您的建議（1）也可以通過commonj WorkManager在WebSphere或Weblogic上執行。它將允許您在這些環境中創建託管線程，並且非常輕便。

WorkManager and TimerManager API

Answer 2

我們使用MDBs，其中隊列被保存在數據庫中，如果系統停機，這些數據庫的好處是信息不會丟失。

您可能還希望在參與方之間建立異步合同。我的意思是，客戶會給你發一條消息，而不是你做大量的重量處理並返回響應，你只需發送一個確認響應，然後發送一個異步消息給他們，並得到完整的結果。

您還應該建立一個協議，允許客戶重新發送一條消息，如果他們沒有收到完整的響應，在一個確定的時間內。

Answer 3

你可以嘗試用Atomikos MessageDrivenContainers（消息驅動的POJO）重量輕MDB的方法。您的應用程序將更加輕量級，更好的可測試性，也可能更具可擴展性。

請參閱http://www.atomikos.com/Publications/J2eeWithoutApplicationServer。

HTH

蓋伊