问题

  • 直到什么时候JSF在服务器端保存UI组件的状态以及何时从服务器内存中删除UI组件的状态信息?当应用程序上的登录用户浏览页面时,组件的状态是否会继续累积在服务器上?
  • 我不明白在服务器上保持UI组件状态有什么好处?是不是直接将经过验证/转换的数据传递给托管bean?我可以或者应该尽量避免它吗?
  • 如果有数千个并发用户会话,那么在服务器端消耗的内存是否过多?我有一个应用程序,用户可以在某些主题上发布博客。这个博客的规模非常大。当有回复或请求查看博客时,这个大页面数据是否会被保存为组件状态的一部分?这会耗费太多记忆。这不是一个问题吗?

#更新1:

现在,在使用JSF时不再需要保存状态。可以使用高性能无状态JSF实现。有关详细信息和讨论,请参见blogthis question。此外,还有一个openissue包含在JSF规范中,为JSF提供无状态模式的选项。 (P.S.考虑对问题进行投票thisthis这是一个有用的功能。)

#Update 2(24-02-2013):

一个好消息Mojarra 2.1.19with withstateless mode

看这里:
http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless?force=255http://java.net/jira/browse/JAVASERVERFACES-2731http://balusc.blogspot.de/2013/02/stateless-jsf.html


#1 热门回答(191 赞)

为什么JSF需要在服务器端保存UI组件的状态?

因为HTTP是无状态的,JSF是有状态的。 JSF组件树受动态(程序)更改的影响。 JSF只需要知道将表单显示给最终用户时的确切状态,以便在表单提交回原始JSF组件树时,它可以基于原始JSF组件树提供的信息成功处理整个JSF生命周期。服务器。组件树提供有关请求参数名称,必要的转换器/验证器,绑定的托管bean属性和操作方法的信息。

在什么时间点,JSF会在服务器端保存UI组件的状态,以及何时从服务器内存中删除UI组件的状态信息?

这两个问题似乎归结为同样的问题。无论如何,这是特定于实现的,还取决于状态是保存在服务器还是客户端上。有点不错的实现将在它过期或队列已满时将其删除。例如,当状态保存设置为会话时,Mojarra的默认限制为15个逻辑视图。这可以通过web.xml中的以下上下文参数进行配置:

<context-param>
    <param-name>com.sun.faces.numberOfLogicalViews</param-name>
    <param-value>15</param-value>
</context-param>

另见Mojarra FAQ其他Mojarra特有的params和这个相关的答案com.sun.faces.numberOfViewsInSession vs com.sun.faces.numberOfLogicalViews

当应用程序上的登录用户浏览页面时,组件的状态是否会继续在服务器上累积?

从技术上讲,这取决于实施。如果你正在谈论页面到页面导航(只是GET请求),那么Mojarra将不会在会话中保存任何内容。如果它们是POST请求(带有commandlinks / buttons的表单),那么Mojarra将在会话中保存每个表单的状态,直到达到最大限制。这使最终用户可以在同一会话中的不同浏览器选项卡中打开多个表单。

或者,当状态保存设置为客户端时,JSF将不会在会话中存储任何内容。你可以通过以下上下文参数在web.xml中执行此操作:

<context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
</context-param>

然后,它将序列化为隐藏输入字段中的加密字符串,其名称为javax.faces.ViewState

我不明白在服务器端保持UI组件状态的好处是什么。是不是直接将经过验证/转换的数据传递给托管bean?可以/我应该尽量避免吗?

这还不足以确保JSF的完整性和健壮性。 JSF是一个具有单一控制点的动态框架。如果没有状态管理,就可以以某种方式欺骗/破解HTTP请求(例如,操纵disabled,readonlyrendered属性),让JSF做出不同的 - 并且可能具有危险性的事情。它甚至会容易发生CSRF攻击和网络钓鱼。

如果有数千个并发用户会话,那么服务器端的内存消耗不会太多吗?我有一个应用程序,用户可以在某些主题上发布博客。这个博客的规模非常大。当有回访或请求查看博客时,大型博客将被保存为组件状态的一部分。这会消耗太多内存。这不是一个问题吗?

记忆特别便宜。只需给appserver足够的内存。或者,如果网络带宽对你来说更便宜,只需将状态保存切换到客户端即可。要找到最佳匹配,只需使用预期的最大并发用户数进行压力测试并分析你的webapp,然后为应用程序服务器提供最大测量内存的125%~150%。

请注意,JSF 2.0在状态管理方面已经有了很大改进。可以保存部分状态(例如,只保存部分状态,而不是整个部分从<html>保存到最后)。例如Mojarra就是这么做的。具有10个输入字段(每个字段带有标签和消息)和2个按钮的平均表单不会超过1KB。在会话中有15个视图,每个会话不应超过15KB。有大约1000个并发用户会话,应该不超过15MB。

你应该更关注会话或应用程序范围中的真实对象(托管bean和/或甚至数据库实体)。我已经看到很多代码和项目不必要地将整个数据库表复制到Java的内存中,其中使用了Java而不是SQL来过滤/分组/排列记录。有大约1000条记录,很容易超过10MB的用户会话。


原文链接