關於會話EJB的使用，我迄今爲止在「真實世界中的應用程序」（如果我記得正確的話）中所看到的是無狀態會話EJB，用作事務性的「外牆」（通過CMT ）業務邏輯方法。不過，我還沒有看到任何有狀態的會話EJB。事實上，它們似乎被用作例如Java EE書中的「購物車」，這意味着它們的狀態應該以某種方式存儲在持久性存儲中。但是這似乎表明，在數據庫中建模的應用程序域的其他部分也應映射到有狀態的EJB-s，這似乎過於複雜。有狀態會話EJB的真實世界用例
那麼，您能否根據您的經驗/專業知識給出具體的例子，說明當今（而不是2003年）應用程序中使用有狀態會話EJB的方式？
有狀態EJB可以在數據庫中持久化它們的狀態，但有狀態EJB不一定需要在數據庫中持久化它們的狀態。有狀態的EJB只有在「對話」期間纔有義務在內存中存儲和記憶與客戶端的會話狀態。
下面你會發現在某些情況下，根據Java EE 7 Tutorial適合狀態EJB使用確定了一些真實的例子：如果以下任一條件，則 狀態會話bean是適當的。
bean的狀態表示bean和特定客戶端之間的交互。真實世界示例：使用登錄，操作和註銷的在線事務的有狀態EJB實現。
bean需要在方法調用中保存有關客戶端的信息。真實世界示例：有狀態EJB可用於實現購物卡。數據可以被保存或不被保存，例如對於不需要登錄的eshop而言，如果用戶沒有最終檢出他收集的物品，則可以丟棄購物卡。
bean在客戶端和應用程序的其他組件之間進行調解，向客戶端呈現簡化的視圖。有狀態EJB可用於實現持久性抽象。
在幕後，bean管理着幾個企業bean的工作流程。真實的例子：有狀態的EJB可以用來實現一個在線假期預訂事務，在這個事務中，EJB建模一個代理，它使用其他EJB從不同的提供者處預訂機票，汽車和酒店，然後將結果返回給客戶端。
上面的例子說明了這個概念在一些例子中的適用性。實際上，在現實環境中使用有狀態的EJBs會導致更純的設計，但如果考慮到性能和複雜性，它不會是最佳的。另見Stateful EJBs in web application?。
我們目前在生產中運行的其中一個應用程序中有幾個有狀態的EJB。所以我想，它可以被認爲是一個真實世界的例子。
該EJB用於通過將這些數據分成塊並按需發送這些塊來向客戶端提供大量數據。所有這一切的工作原理如下：
是一個有狀態的bean是解決這個問題的必要嗎？一點也不。
描述的功能可以通過無狀態bean來實現。但在這種情況下，我們只有兩種實施方式。無論我們每次客戶需要下一個數據塊時（因爲我們沒有任何狀態），我們都不得不爲每個請求準備結果集，否則我們會使用一些靜態存儲並關注我們自己的安全性和併發訪問。 /保安在這裏我的意思是，其中一個客戶端可以使用他的描述符訪問結果集的另一個預防的情況下/
第一種方式是簡單地慢，效率較低的比較上有狀態bean的實現。由於同步，第二種方法更加複雜並且在負載下不太穩定。
使用有狀態bean，我們只需要以高效的方式獲得我們所需的內容，而無需額外的工作。
我試圖演示有狀態EJB在一組有狀態EJB適用情況下的適用性。我習慣將EE教程作爲適用案例的參考，並根據個人經驗提供簡化示例。您的澄清表明，您更有興趣瞭解該概念是否真正有益於實際操作。我會說，事實上有狀態的EJB往往會被避免，而無狀態的EJB是更好的性能和簡單性的首選。其他人就是這麼想的。 http://stackoverflow.com/questions/2811312/stateful-ejbs-in-web-application?rq=1 –