为什么不使用CDI支持的bean（而不是SFSB）来保存会话信息？
上下文
简单JavaEE 6（JBoss AS 7.1）CRUD Web应用程序，使用@命名的后备bean，@SessionScope的JSF页面：
问题
为什么在CDI bean上存储HTTP会话状态是个坏主意？例如，在那里存储购物车项目。
评论
由于SFSB的会话状态，它就是为了实现这一点，但我已经读到它们在实践中并不容易使用。我还认为另一个选项是HttpSession对象。
我也知道它们的钝化/激活优势。
共有2个答案
以下是SFSB的假定好处：
- SFSB是事务性的。
- SFSB可以钝化/激活。
- SFSB启用扩展持久化上下文。
为此付出的代价是异常方案更加复杂（回滚、非回滚异常等）。），生命周期也是如此，结果是调试。
通常，您不需要钝化/激活。要使设计具有可伸缩性，请尽可能少地存储在内存中。通常，也不需要扩展持久性上下文（尽管它们有自己的用途）。
但是，请求必须以事务方式处理。但你不需要SFSB。您可以自己处理错误和恢复，以确保您的HttpSession是一致的。不过，请确保使用事务访问后端！
我认为您混淆了用于HTTP会话的“会话”和用于具有特定bean（本例中为有状态bean）的会话的“会话”。
它们有不同的用途，但也有重叠。最初，与SFSB的会话用于非HTTP远程客户端（小程序和Swing应用程序）。在某种程度上，您可以说它是与HTTP会话等效的RMI。
当已经有HTTP会话可用时，使用有状态会话bean来实现这一目的是没有意义的，最好使用HTTP会话范围的bean。
有状态会话bean确实有它们的用途，例如，它们能够适应扩展的持久性上下文，并且可以在事务之外保持（乐观的）锁打开。
在JavaEE 6 Web应用程序中使用时，您通常希望为有状态会话bean分配HTTP会话范围。否则，即使bean有一个内部会话，它也不会连接到任何东西，而是连接到您用来与其通信的代理。
另见：
- 在有状态EJB3.1bean中保持会话
-
问题内容： 我只是在GlassFish服务器下引发了臭名昭著的JavaEE CDI错误： 该错误非常明显，因为他不喜欢CDI bean中的最终方法，但是我不明白为什么。 在此链接 http://docs.jboss.org/weld/reference/1.1.0.Final/zh- CN/html_single/#d0e1429 他们解释说，这与序列化有关，但我看不出为什么用final方法序列化
-
有状态会话bean定义如下： 无状态会话bean无状态会话bean不维护与客户端的会话状态。当客户机调用无状态bean的方法时，该bean的实例变量可能包含特定于该客户机的状态，但仅限于调用期间。当方法完成时，客户端特定状态不应保留。然而，客户端可能会更改池化无状态bean中实例变量的状态，并且此状态将保留到下一次调用池化无状态bean时。除了在方法调用期间，无状态bean的所有实例都是等效的，允
-
本文向大家介绍为什么Java不支持<<相关面试题，主要包含被问及为什么Java不支持<<时的应答技巧和注意事项，需要的朋友参考一下 Java添加了运算符“ >>>”来执行逻辑右移，但是由于 逻辑和算术左移运算是相同的 ，因此Java中没有“ <<<”运算符。 来自Java的Shifts …
-
问题内容： 我已经使用Flask一段时间了，我真的很喜欢这个框架。我无法理解的一件事是，在几乎所有其他地方，他们都在谈论将会话存储在服务器上，并将会话ID存储在客户端上，然后标识会话。但是，使用烧瓶后，我觉得没有必要这样做。以加密方式将会话另存为客户端cookie符合我的目的，而且似乎也很安全。唯一的原因是我无法为以下项加密会话密钥： 会显示为 在客户端上保存的Cookie中。但是，由于它仍处于加
-
我需要确保给定的 bean 是使用会话范围定义的。 我知道我可以使用或，其中是我的（Web）Application Context，但是，没有。 如果你想知道为什么我需要这样的东西，请检查这个问题。 相关：我可以以编程方式确定Spring bean是否不是单例吗？
-
例如，在这个问题的最上面的答案中：javaee6@javax。注释。ManagedBean与@javax。注射命名vs.@javax。面孔。ManagedBean我读到： 要部署CDIBeans，必须放置一个名为bean的文件。类路径上META-INF文件夹中的xml。一旦您这样做，那么包中的每个bean都将成为CDIBean。 据说： 如果希望从JSF页面使用CDIBean，可以使用javax为