之前只知道session是基于cookie的,如果禁用cookie后session就可放在url里面。
今天做了一件事情,用一个监听器来监听session的创建时间。
1.我第一次访问web服务,发现session创建。
后来再次访问,不再创建session。这个是大家都知道的。
2.我第一次访问web服务,发现session创建。
然后我重启服务器,(在不重启浏览器的情况下)继续访问web服务,发现没有创建新的session。
这也就是说明,当我重启服务器之后,我的session还在。
通过查阅资料得知:在tomcat的默认配置中,session是可持久话存在的,但是session中的对象在重启后就不存在了。
在tomcat的work目录下的ser文件其实就是session的持久话存储文件。
现在又有一个问题了,tomcat为什么要实现session的持久话存储?我们能够利用这个东西做什么?
现在假设一个场景,我想重启服务器,但是重启之后我所有的已登录用户(存在session中)就必须要重新登录。
如果我想要实现已登录用户不再重新登录,那么就需要将session持久话存储到服务器。
同时为了将session中的对象也存储起来,那么session中的对象就必须是可序列化的,即实现serializable接口。
今天做了一件事情,用一个监听器来监听session的创建时间。
1.我第一次访问web服务,发现session创建。
后来再次访问,不再创建session。这个是大家都知道的。
2.我第一次访问web服务,发现session创建。
然后我重启服务器,(在不重启浏览器的情况下)继续访问web服务,发现没有创建新的session。
这也就是说明,当我重启服务器之后,我的session还在。
通过查阅资料得知:在tomcat的默认配置中,session是可持久话存在的,但是session中的对象在重启后就不存在了。
在tomcat的work目录下的ser文件其实就是session的持久话存储文件。
现在又有一个问题了,tomcat为什么要实现session的持久话存储?我们能够利用这个东西做什么?
现在假设一个场景,我想重启服务器,但是重启之后我所有的已登录用户(存在session中)就必须要重新登录。
如果我想要实现已登录用户不再重新登录,那么就需要将session持久话存储到服务器。
同时为了将session中的对象也存储起来,那么session中的对象就必须是可序列化的,即实现serializable接口。