在 Java Web 应用程序中使用会话的主要用例
我一直试图避免使用会话。我使用了 spring security 或其他方式让用户登录应用程序，我认为这是使用会话的主要用例。
但其他用例是什么？你能列出那些最重要的吗？为什么我能够在不使用会话的情况下开发甚至复杂的应用程序？
是因为我使用的是 spring-mvc 并且除了登录之外实际上不需要使用 Sessions 吗？
编辑：伙计们，这个问题是在询问用例......大多数答案都解释了会话的用途。如果我们总结一些用例，我们可以肯定地说，何时使用数据库或会话来维护对话状态...... 您不记得需要会议的任何具体场景吗？在过去的几年中:)
例如，某些对话状态可能会在某个点/事件之后变得持久。在本例中，我从一开始就使用数据库。
I've been always trying to avoid using Sessions. I've used spring security or other ways of having user logged in the application, which is I suppose the major use case for using Sessions.
But what are the other use cases ? Could you please make a list of those most important ones ? How come that I've been able to develop even complicated applications without using Sessions?
Is it because I'm using spring-mvc and using Sessions is practically not needed except the login stuff ?
EDIT: Guys this question was asking for use cases... Most of the answers explains what are sessions for. If we summarize some usecases, we can say for sure, when to use database or sessions for maintaining conversation state...
Don't you remember any concrete scenarios you needed sessions for? For past years :)
for instance some conversational state may become persistent after some point / event. In this case I'm using database from the beginning.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我认为您可以做任何您想做的事情，而无需在会话中存储任何内容。
当我不想向客户端发送敏感信息（即使以加密形式）时，我通常使用会话来避免在客户端和服务器之间传递状态（以 id 为例）和因为这可能是一个安全问题。
避免使用会话的其他方法是：
使用会话真正有用的一个用例是会话，尽管通常框架在幕后管理该会话，并将会话存储在会话中。
编辑转换
（以我的理解）类似于向导，您可以在其中完成不同页面中的多个表单，最后执行操作。例如，在结账过程中，用户在不同的页面中输入他的姓名、送货地址和信用卡详细信息，但您希望在最后提交订单，而不在数据库中存储任何中间状态。
我所说的敏感信息，想象一下在前面的示例中，一旦用户发送了他的信用卡详细信息，您就不应该以任何格式（甚至加密）将该信息返回给用户。我知道这有点偏执，但这就是安全:)。
I think you can do anything you want without storing anything on a sessions.
I usually use the sessions to avoid having to pass state between the client and server (used id as an example) and when I don't want to send sensitive information to the client (even in encrypted form) as it might be a security problem.
Other ways of avoiding using the session are:
One use case when it's really useful to use the session is for conversations, although usually frameworks manage that behind scenes, and store the conversation in the session.
edit
Converstions (in my understanding) are something like wizards, in which you complete several forms in different pages and at the end you perform the action. e.g. in a checkout process, the user enters his name, shipping address and credit card details in different pages, but you want to submit the order just at the end, without storing any intermediate state in your DB.
By sensitive information I mean, imagine in the previous example, once the user sent his credit card details, you shouldn't return that information in any format (even encrypted) to the user. I know it's a bit paranoid, but that's security :).
在我正在开发的电子商务系统中，后端有一个外部系统，用于存储用户保存的送货和账单地址。我们的网络应用程序通过调用网络服务来检索这些地址来与其对话。当我们获得地址时，我们将它们存储在会话中。这样，当用户第一次查看他们的地址时，我们只需调用该服务一次，而不是每次我们提供需要地址信息的页面时。我们对地址有一个生存时间，因此如果地址发生变化（例如，如果用户致电客户服务台更改地址），我们最终将获取新的地址。
可以将地址存储在我们的数据库中，而不是存储在会话中。但我们为什么要这样做呢？它是暂时的信息，已经永久存储在其他地方。会议是它的理想场所。
In the ecommerce system i'm working on, there is an external system at the back-end which stores users' saved shipping and billing addresses. Our web app talks to it by making web service calls to retrieve those addresses. When we get the addresses, we store them in the session. That way, we only have to call the service once, when the user firsts looks at their addresses, and not every time we serve a page which needs address information. We have a time-to-live on the addresses, so if the addresses change (eg if the user telephones the customer service desk to change an address), we will eventually pick up the fresh ones.
It would be possible to store the addresses in our database, rather than in the session. But why would we? It's transient information which is already stored permanently somewhere else. The session is the ideal place for it.
好吧，从某种意义上说，你的问题很深刻（会话的特殊之处值得了解），从另一种意义上说，它很浅薄（如果我不使用它们，我不能做什么，结果是一个有点奇怪的问题
） Session 只是（或可能是）一个 ConcurrentHashMap（事实上它通常不是线程安全的），其中唯一的会话 ID 的键作为 cookie 传递。您知道为什么它很有用，但是要回答您的用例
= 由许多本地化实用程序使用
您可以使用数据库或您自己的哈希图实现/过滤器来完成所有这一切吗？当然，Sessions 并没有什么神奇之处。它们只是一个方便的标准，用于让某些对象跟随登录用户并与该用户使用应用程序的生命周期相关联。
为什么使用 Servlet？您还可以实现自己的套接字级别标准吗？答案是使用标准 api/实现提供便利，并在其基础上构建其他库。
缺点是
Well in one sense your question is deep (what's SPECIAL about a session is worth knowing) and in another sense it's shallow (what can't I do if I don't use them turns out to be a somewhat odd question)
In the end a Session is merely (or could be) a ConcurrentHashMap (in fact it usually isn't that threadsafe) with a a key of unique session id passing as the cookie. You know why it's useful, but to answer you for use cases
= used for by a lot of localization utilities
Can you do all this with a database or your own hashmap implementation/filter? Of course, there's nothing magical about Sessions. They are merely a convenient standard for having some objects follow a logged in user and be tied to the lifetime of that user's use of the application.
Why do you use Servlets? You could also implement your own socket level standard? The answer to that is using standard apis/implementations provides convenience and other libraries build upon them.
The cons are
会话是跨多个请求（例如多个无状态 HTTP 请求）维护会话状态的一种方法。
还有其他实现会话状态的方法，例如，将身份验证令牌或某些合适的会话 id 存储为 cookie 并维护会话 id 的存储到会话状态。 （本质上，复制应用程序服务器在提供会话时正在执行的操作。）
您不需要使用会话意味着您的应用程序不需要会话状态，或者您已经以不同的方式实现了它。例如，也许您的应用程序使用身份验证令牌（例如 cookie）并将所有状态更改保存到数据库中。有了这种安排，就不需要对话状态了。
Sessions are one way of maintaining conversational state across multiple requests (e.g. multiple stateless HTTP requests.)
There are other ways of implementing conversational state, for example, storing an authentication token or some suitable conversation id as a cookie and maintaining a store of conversation id to session state. (In essence, duplicating what the app server is doing when it provides sessions.)
That you haven't needed to use sessions means that your application either doesn't need conversational state or you've implemented it in a different way. For example, perhaps your application uses an authentication token (say a cookie) and persists all state changes to the database. With that kind of arrangement, there is no need for a conversation state.
您好，您可以以购物车为例，因为由于 Http 是无状态协议，因此它不会维护发送请求的用户的状态。
例如
如果一个用户发送了从 eBay 购买相机的请求，几分钟后另一个用户发送了购买笔记本电脑的请求。
但是由于http是无状态协议，因此服务器无法分离用户发送的请求，并且可能会发生笔记本电脑的账单给第一个用户的情况。
因此，通过会话，我们可以在服务器端为特定用户维护特定实体。
Hi you can take an example of shopping cart because since Http is stateless protocol it does not maintain the status of the user who sends the request.
For e.g.
If one user sends a request to buy camera from say eBay and after some minutes another user sends a request to buy laptop.
But since http is stateless protocol so server is not able to separate the request send by the users and may it happen that the bill of the laptop may be given to first user.
So through session we can maintain a particular entity over the server side for a particular user.