jsf - 在 JSF 中将数据保存到 session

Question

我是 J(2)EE 和 Web 应用程序开发领域的新手，但我很快就了解了它并学到了很多东西。每一天对我来说都是一次奇妙的新发现之旅。

我目前正在开展一个项目，在该项目中我在 Glassfish v2 上使用 Visual JSF Woodstock。我对 JSF 也很陌生。

有时我需要在请求之间保存一些对象(例如 MyObject)。根据我目前阅读和理解的内容，我需要使用 session 在不同请求之间保存这些对象。到现在为止还挺好。

究竟如何做到这一点是我关心的地方。我知道在 JSP 中你可以使用 session.setAttribute("myObj", myObject)这将使用 cookie 或 url 重写或隐藏的表单变量在客户端保存对象。

另一方面，在 JSF 中，我使用 Session 范围的 bean，例如说 SessionBean1，并将对象保存为 SessionBean1 属性(例如 SessionBean1.setSomeOjb(myObj) )。这是正确的方法吗？

我猜测这样做会导致服务器端的内存利用率增加，因为每个请求都将创建 session 范围 bean 的新实例 SessionBean1 加上 SessionBean1 中保存的 myObject 实例所使用的内存。

我已经读到你可以使用 FacesContext.getExternalContext().getSession/getSessionMap()这将在客户端保存 session 变量。

那么您建议我使用哪种方法 - session 作用域 bean 或 sessionmap 来保存对象以在 session 请求之间进行访问？

谢谢。

Answer 1

一般来说，Java EE Web Apps 不希望在客户端保存 session 数据。您担心服务器端的 session 膨胀是正确的，一个常见的问题是拥有巨大的 session 足迹，这可能会导致严重的资源和性能问题，尤其是在集群环境中。

我想知道你在哪里看到

I have read that you can use FacesContext.getExternalContext().getSession/getSessionMap() which would save session variables at client side.

我相信(在这一点上纠正我)这只是允许访问 HttpSession 对象，然后您可以在该对象上使用相同的

 session.setAttribute("myObj", myObject)

这本身不会将对象发送回客户端，它保存在服务器中并由某个 session 标识符进行键控，通常在 cookie 中传递。

现在还有另外两种技术:您可以明确选择将数据放入您自己制造的 cookie 中——您可以从 JSF 或 JSP 访问的 servlet API 允许您这样做，或者您可以在表单上使用隐藏字段，以及因此传递aorund session 数据。

但考虑到这一点。我使用的 App Server 上的一个经验法则是 1k-4k 数量级的 HttpSession 往往不是问题。比这更大(我已经看到以兆字节为单位的 session )确实会给基础设施带来压力。如果您担心这种大小的 session ，您是否希望在每次请求时将 cookie 或隐藏字段中的兆字节数据发送回浏览器？即使是 1k-2k 也可能有点大。

所以建议:

把事情简单化。使用 Session API 或其 JSF 表现形式。

控制 session 中的数据量。

在回答有关聚类的问题时添加:

通常，在集群环境中，我们具有 session 亲缘关系，以便将请求发送回同一个集群成员。然而，当请求转到不同的服务器时，我们仍然需要考虑这种情况(也许如果集群成员失败)。

一些 App Server 供应商提供 session 复制，要么通过直接的服务器间通信，要么通过将 session 持久化到数据库——显然这里有开销，所以有时，对于低值(value)的 session ，我们只接受在发生故障时 session 丢失。

有一种观点认为，如果 session 数据具有很高的值(value)，那么它应该由应用程序持久化，它实际上是业务数据，应该这样对待。越来越多的 NOSQL 数据库(例如 Cloudant 或 MongoDb)用于此目的。在这种情况下，我们可以将 HTTP session 视为缓存，因为知道在发生错误时可以检索 session 数据。

所以我认为购物车很可能对企业有相当大的值(value)；它代表着客户对他们想要花钱的东西的周到积累。所以它应该被持久化，而不是仅仅保留在 session 中。一旦我们决定坚持它，我们就会发现它会导致其他有趣的场景，例如跨多个客户端设备的整合体验。客户开始在家中使用台式 PC 购物，但在网上完成购买。

所以还有一个原则:

3)。不要仅仅因为它存在就过度使用 HTTP session 。考虑数据的商业值(value)以及它是否应该被持久化。