【发布时间】:2012-12-18 17:55:57
【问题描述】:
我想知道确切地 HttpSession 何时过期(与销毁不同)?
我正在尝试确定 session.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000) 是否会在每次请求带有相同会话 ID 时为我提供会话到期的确切时间(以毫秒为单位)!
来自 javadocs:
long getLastAccessedTime()
Returns the last time the client sent a request associated with this session, as the number of milliseconds since midnight January 1, 1970 GMT, and marked by the time the container received the request.int getMaxInactiveInterval()
Returns the maximum time interval, in seconds, that the servlet container will keep this session open between client accesses.
假设我们有以下内容:
Treq1 - the time the container received the 1st request (HttpSession.lastAccessedTime)
Tresp1 - the time the container sends the 1st response
Preq1 - the time period between Treq1 and Tresp1 (the time period that the server processes the 1st request
Treq2 - the time the container received the 2nd request (HttpSession.lastAccessedTime)
Preq1req2 - the time period between Treq1 and Treq2 (the time between requests entering the container)
Presp1req2 - the time period between Tresp1 and Treq2 (the time between the 1st response exiting the container and the 2nd request entering the container)
那么现在,服务器什么时候计算会话过期?什么时候:
1. Treq1 + maxInactiveInterval maxInactiveInterval
2. Tresp1 + maxInactiveInterval maxInactiveInterval
这部分,the servlet container will keep this session open between client accesses 有点混乱。是在请求进入容器之间还是在响应退出和请求进入之间?
附带说明,我知道会话可能不会在确切的到期时间被销毁,但我不知道知道它是否在容器中发生任何请求处理逻辑之前被销毁。我指的是持有过期会话 id 的请求。
亲切的问候,
暴君
【问题讨论】:
-
为什么重要?请求的时间通常是几毫秒。会话超时通常为 30 分钟。是 30.000 还是 30.002 有关系吗?你的最终目标是什么?无论如何,答案就在问题中:并以容器收到请求的时间标记
-
这很重要,因为我想在客户端确切地知道会话何时到期。 “答案就在问题中:并由容器收到请求的时间标记”这可能仅指 lastAccessedTime。你确定过期时间是 session.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000) (1.case)?有没有可以证实的消息来源?感谢您的评论!
-
您想要精确到毫秒吗?最终用户是否关心它是在 30 分钟内还是在 30 分 8 毫秒内?无论如何,那个时候会话不会被销毁,因为容器通常使用一个后台线程,每分钟左右销毁过期的会话。
-
首先,服务器上的处理可能需要超过 8 毫秒,其次,我需要确保我没有在会话过期的某个端点发送请求(并且我想最大化我向该端点发送请求的时间)。 “那个时候会话不会被破坏”我明白这一点(参见“旁注”部分)。这并不能回答服务器过期时间(不破坏时间)的问题。我想先了解一下,服务器到底是怎么计算过期时间的。
-
确保您没有向超时会话发送请求的方法是发送它并处理由此产生的错误情况。无论如何你必须这样做。任何预测方法迟早都会失败,在现实中无非是算命。
标签: java spring httpsession