我有幾個關於EJB事務的問題。我有一種情況,一個進程已經變得更長時間運行了,而且由於超出了服務器超時而有時會失敗。雖然我最初增加了超時(包括總事務和最大事務),但對於長時間運行的流程,我知道將這項工作儘可能分割成更小的工作單元是非常有意義的, 。因此,我正在根據以下背景和隨後的問題尋找關於下一步行動的一些想法或參考。重新設計POJO到EJB或客戶端事務
環境: EJB 3.1,JPA 2.0中,WebSphere 8.5
背景: 我建了一個組POJO做一些面向批處理工作的企業應用程序。它們是非EJB POJO,旨在實現多個業務流程(5個相關的順序流程,每個流程都依賴於它的前身)。 POJO使用普通的Java項目,而不是EJB項目。
但是,這些POJO通過JPA訪問EJB Facade以訪問數據庫。 5個業務流程的抽象核心執行EJB Facade的JNDI查找,以返回域對象進行處理。最初,設計是完全從服務器運行,但是,需要引發外部這些進程。因此,我創建了一個EJB包裝程序,以便進程可以遠程調用(單獨或作爲基於常用策略接口的單個進程)。不幸的是,數據的大小,包括行寬和行數都大大超出了原來的意圖。
完成這些批處理所需的處理時間已經顯着增加(從幾個小時到大約1/2天,並且可能會增加)。 5個進程中只有一個對多線程有意義(我確實多線程實現了它)。因爲我有包裝器EJB來啓動1或全部,所以我決定爲每個進程創建一個新的容器事務,而不是作爲單個進程運行所有「單個默認事務」時的「必需」。由於一個進程是多線程的,因此嘗試爲每個線程創建一個新的事務是有意義的,然而,作爲一組POJO,我沒有事務處理能力。
問題: 所以我的問題是,什麼更有意義,爲什麼?將POJO重新設計爲EJB本身,並讓包裝EJB將每個進程實例化爲子進程,其中每個進程都可以擁有自己的事務,更重要的是,多線程進程可以爲每個線程創建一個事務。或者,嘗試從容器中的JNDI查找中嘗試在POJO中創建UserTransaction並嘗試將其作爲bean管理的事務進行管理(如果這是一個可行的解決方案),會更有意義。我知道這可能與應用程序有關,但對於Java EE容器的超時而言,有什麼合理之處?顯然,我不想逃跑進程,但想確保我可以完成這些批處理。
不幸的是,這個應用程序已經被部署爲一個生產系統。重新設計,儘管它可能不過是將策略邏輯組裝在EJB中,但對功能的重大改變。
我在這裏和通過一般的互聯網搜索找了一些其他的線程,但我想我會看到如果任何人有完全的另一個或另一個解決方案的引人注目的論據。討論像這樣的話題的其他鏈接是值得讚賞的。我摔跤是否發佈這個,因爲有些人可能把這個看作是主觀的,但是,我認爲這個狹窄的話題值得這個職位,並且可能與嘗試這樣的流程的其他人相關。
Arjan,謝謝你糾正我的大寫和標點符號。我會盡量記住,這些標題和標點對於這些帖子很重要。我猜想我的壞習慣。 – jrsdev