关于会话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 –