在 Java Web 应用程序中使用会话的主要用例答案

【问题标题】：Top use cases for using Sessions in Java web application在 Java Web 应用程序中使用会话的主要用例
【发布时间】：2020-11-08 15:28:17
【问题描述】：

我一直试图避免使用 Sessions。我已经使用 spring security 或其他方式让用户登录应用程序，我想这是使用 Sessions 的主要用例。

但是其他用例是什么？你能列出那些最重要的吗？为什么我能够在不使用 Sessions 的情况下开发更复杂的应用程序？

是不是因为我使用的是 spring-mvc 并且除了登录的东西之外几乎不需要使用 Sessions 吗？

编辑：伙计们，这个问题是在询问用例......大多数答案都解释了会话的用途。如果我们总结一些用例，我们可以肯定地说，何时使用数据库或会话来维护会话状态...... 你不记得你需要会话的任何具体场景吗？过去几年:)

例如，某些会话状态可能在某个点/事件之后变得持久。在这种情况下，我从一开始就使用数据库。

【问题讨论】：

您避免会话的原因是什么？我不明白这里的目标；你避免会议，为什么？你为什么要寻找不避免会话的原因，因为你可以在没有会话的情况下工作？会话只是存储在服务器上的状态；编写完全无状态的应用程序是可能的，但根据应用程序的不同会很困难，因此您要么在这些域中工作，要么将状态存储在其他地方。
也许我是偏执狂，但由于我实际上并没有正确使用 Sessions，我不确定我是否可以依赖它以及我应该期待什么缺点。例如，考虑一个 html 表单中的 flash 上传器，它一个接一个地上传一系列文件，您需要将 fileID 存储到会话/数据库中，并通过 ajax 将它们返回到 html 表单并提交。我宁愿选择将其保存到数据库中。我可以 100% 确定不会发生任何意外，因为我确实可以控制它。我可以在未来分析使用数据并设置调度程序以删除死条目。
如果你的数据库崩溃了怎么办？ :) 我并不是建议您使用会话而不是数据库；我只是发现避免瞬态数据的会话有点奇怪，因为这就是会话概念的用途。您是否希望您的 Web 应用程序在随机点崩溃，无缘无故地突然崩溃？
也许我应该以不同的方式提出问题。我可能应该相信会话并使用它们而不是数据库。我现在才问，因为我开始意识到这一点:-)
我认为这是一个合理的问题。我认为实际上有一个强有力的论据可以将所有重要的东西都保存在数据库中而不依赖于会话；这意味着您的服务器不必维护状态，这意味着如果一个崩溃，或者您需要添加更多，或者如果您需要将用户从一台超载的机器上移走，一切都会继续工作，而如果您有有状态的服务器，您有担心会话迁移和故障转移，这当然是可能的，但会带来相当大的编程和运行时开销。

标签： java session spring-mvc

【解决方案1】：

我认为你可以做任何你想做的事，而不用在会话中存储任何东西。

我通常使用会话来避免在客户端和服务器之间传递状态（以 id 为例）和当我不想向客户端发送敏感信息时（即使在加密形式），因为这可能是一个安全问题。

避免使用会话的其他方法是：

在数据库中存储一些状态，例如购物车，而不是在会话中，即使购物车在一定时间后被丢弃。
在 cookie 中存储状态，例如用于用户定制

使用会话真正有用的一个用例是对话，尽管通常框架在幕后管理它，并将对话存储在会话中。

编辑

转换（在我的理解中）类似于向导，您可以在其中完成不同页面中的多个表单，最后执行操作。例如在结帐过程中，用户在不同的页面中输入他的姓名、送货地址和信用卡详细信息，但您希望在最后提交订单，而不在您的数据库中存储任何中间状态。

我的意思是敏感信息，想象在前面的示例中，一旦用户发送了他的信用卡详细信息，您不应该以任何格式（甚至加密）将该信息返回给用户。我知道这有点偏执，但这就是安全性:)。

【讨论】：

“对话”是什么意思？你有没有一个例子：“当我不想向客户发送敏感信息时”？

【解决方案2】：

在我正在开发的电子商务系统中，后端有一个外部系统，用于存储用户保存的送货地址和帐单地址。我们的 Web 应用程序通过调用 Web 服务来检索这些地址来与之对话。当我们获得地址时，我们将它们存储在会话中。这样，当用户第一次查看他们的地址时，我们只需要调用一次服务，而不是每次我们提供需要地址信息的页面时。我们对地址有一个生存时间，所以如果地址发生变化（例如，如果用户打电话给客户服务台更改地址），我们最终会选择新的。

可以将地址存储在我们的数据库中，而不是在会话中。但我们为什么要这样做？它是暂时的信息，已经永久存储在其他地方。会议是它的理想场所。

【讨论】：

【解决方案3】：

好吧，从某种意义上说，您的问题很深（值得了解有关会话的特别之处），而在另一种意义上，问题很浅（如果我不使用它们，我不能做什么，结果是一个有点奇怪的问题）

最后，Session 只是（或可能是）一个 ConcurrentHashMap（实际上它通常不是线程安全的），带有一个唯一会话 id 的键作为 cookie 传递。你知道它为什么有用，但要回答你的用例

集群（这就是状态在节点之间分布的方式）
缓存用户及其对象的一般状态（而不是每次都从数据库重新加载）
内置方法让会话侦听器在某人超时或属性更改时进行观察。 = 被许多本地化实用程序使用

您可以使用数据库或您自己的 hashmap 实现/过滤器来完成所有这些工作吗？当然，Sessions 并没有什么神奇之处。它们只是让某些对象跟随登录用户并与该用户使用应用程序的生命周期相关联的方便标准。

为什么要使用 Servlet？您还可以实现自己的套接字级别标准吗？答案是使用标准的 apis/implementations 提供了便利，其他库也以此为基础。

缺点是

您正在重新发明轮子和一些经过时间测试的代码
您将无法使用大量内置设施进行监控/管理/集群/本地化等。

【讨论】：

【解决方案4】：

会话是跨多个请求（例如多个无状态 HTTP 请求）维护会话状态的一种方式。

还有其他实现会话状态的方法，例如，将身份验证令牌或一些合适的会话 id 存储为 cookie，并将会话 id 存储到会话状态。（本质上，就是复制应用服务器在提供会话时所做的事情。）

您不需要使用会话意味着您的应用程序要么不需要会话状态，要么您已经以不同的方式实现它。例如，也许您的应用程序使用身份验证令牌（例如 cookie）并将所有状态更改保存到数据库。有了这样的安排，就不需要对话状态了。

【讨论】：

【解决方案5】：

您好，您可以举个购物车的例子，因为 Http 是无状态协议，它不会维护发送请求的用户的状态。

例如如果一个用户从 eBay 发送购买相机的请求，几分钟后另一个用户发送购买笔记本电脑的请求。

但是由于http是无状态协议，所以服务器无法分离用户发送的请求，可能会发生笔记本电脑的账单可能会给第一个用户。

因此，通过会话，我们可以在服务器端为特定用户维护特定实体。

【讨论】：

这是用户登录的一部分，因此 userId 在会话中，应用程序可以区分用户。我的意思是除了这个用例之外的所有其他内容:)
也可以在session属性中保存数据。