通常，Java EE Web Apps倾向于不希望在客户端保存会话数据.您应该担心服务器端的会话膨胀，常见的问题是会话占用空间很大，这可能会导致严重的资源和性能问题，尤其是在集群环境中.

In general Java EE Web Apps tend not to expect to save session data client side. You're right to be concerned about session bloat on the server side, a common problem seen is to have huge session footprints which can cause significant resource and performance issues, and can be especially in clustered environments.

我想知道你在哪里

我已阅读到您可以使用FacesContext.getExternalContext().getSession/getSessionMap()来将会话变量保存在客户端.

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

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

I believe (correct me on this point) that this simply gives access to the HttpSession object, on which you can then use the same

 session.setAttribute("myObj", myObject)

这本身并不会将对象发送回客户端，而是保存在服务器中，并由通常通过cookie传递的某些会话标识符作为关键字.

this does not in itself send the object back to the client, it's held in the server and keyed by some session identifier, usually passed in a cookie.

现在有另外两种技术:您可以明确地选择将数据放入自己生产的cookie中-可以从JSF或JSP访问的servlet API可以使您做到这一点，或者可以在自己的隐藏字段中使用表单，并因此传递aorund会话数据.

Now there are two other techniques: you could explicitly choose to put data into a cookie of your own manufacture - the servlet APIs that you can access from JSF or JSP would let you do that, or you can use hidden fields on your forms, and hence pass aorund session data.

但是考虑一下.我使用的App Server的经验法则是HttpSession大约为1k-4k不太可能是一个问题.更大的容量(我已经看到以兆字节为单位的会话数)确实给基础架构带来了压力.如果您担心如此大的会话，您是否希望在每次请求时都将Cookie或隐藏字段中的兆字节数据发送回浏览器?甚至1k-2k也可能有点大.

But consider this. A rule of thumb on the App Server I use is that HttpSession of the order of 1k-4k tend not to be a problem. Larger than that (and I have seen sessions of measured in megabytes) do stress the infrastructure. If you were concerned about sessions of that size would you expect to send megabytes of data in a cookie or hidden field back to the browser on every request? Even 1k-2k is probably a bit big.

所以建议:

1. 保持简单.使用会话API或其JSF表现形式.

1. Keep it simple. Use the Session API, or its JSF manifestation.

保持会话中受控制的数据量.

Keep the amount of data in the session under control.

为回答有关聚类的问题而添加:

Added in response to question about clustering:

通常，在群集环境中，我们具有会话亲缘关系，因此请求可以发送回相同的群集成员.但是，当请求转到另一台服务器时，我们仍然需要考虑这种情况(也许集群成员失败了).

Typically, in a clustered environment we have session affinity, so that requests are sent back to the same cluster member. However we still need to consider the case (perhaps if a cluster members fails) when the request goes to a different server.

一些App Server供应商通过直接服务器间通信或通过将会话持久化到数据库来提供会话复制-显然这里存在开销，因此有时对于低价值会话，我们只接受在发生以下情况时丢失会话失败.

Some App Server vendors offer session replication, either via direct inter-server communication or by persisting the session to a database - obviously there are overheads here, so sometimes, for low value sessions we just accept the loss of session in event of failure.

有一个论点是，如果会话数据具有很高的价值，则应由应用程序将其持久化，它实际上是业务数据，应将其视为此类数据.为此越来越多地使用诸如Cloudant或MongoDb之类的NOSQL数据库.在这种情况下，我们可以将HTTP会话视为缓存，因为在发生错误的情况下可以检索会话数据.

There is an argument that if the session data has high value then it should be persisted by the application, it's actually business data and should be treated as such. Increasingly, NOSQL databases such as Cloudant or MongoDb are used for this. In this case we may think of the HTTP session as a cache, in the knowledge that the session data can be retrieved in the event of error.

因此，我认为购物车可能对企业具有相当大的价值；它代表了客户想要花钱的周到积累.因此，应将其保留，而不是仅保留在会话中.一旦决定坚持下去，我们就会发现它会导致其他有趣的情况，例如跨许多客户端设备的整合体验.客户开始在台式PC上在家购物，但在线完成购买.

So I'd argue that a Shopping Cart may well have considerable value to the business; it represent the customers thoughtful accumulation of things they want to spend money on. So it should be persisted, rather then just kept in the session. Once we decide to persist it, then we find that it leads to other interesting scenarios such as a consolidated experience across many client devices. The customer starts shopping at home on a desktop PC, but completes the purchase online.

进一步的原则:

3).不要仅仅因为HTTP会话就在那儿而过度使用它.考虑数据的业务价值以及是否应保留.

3). Don't over-use the HTTP session just because it's there. Consider the business value of the data and whether it should be persisted.