session 持久化

转：http://www.uzzf.com/news/7573.html

浅述Session的持久化的作用与原理

为什么需要持久化

客户端访问了某个能开启会话功能的资源， web服务器就会创建一个与该客户端对应的HttpSession对象，每个HttpSession对象都要站用一定的内存空间。如果在某一时间段内访问站点的用户很多，web服务器内存中就会积累大量的HttpSession对象，消耗大量的服务器内存，即使用户已经离开或者关闭了浏览器，web服务器仍要保留与之对应的HttpSession对象，在他们超时之前，一直占用web服务器内存资源。

web服务器通常将那些暂时不活动但未超时的HttpSession对象转移到文件系统或数据库中保存，服务器要使用他们时再将他们从文件系统或数据库中装载入内存，这种技术称为Session的持久化。

将HttpSession对象保存到文件系统或数据库中，需要采用序列化的方式将HttpSession对象中的每个属性对象保存到文件系统或数据库中；将HttpSession对象从文件系统或数据库中装载如内存时，需要采用反序列化的方式，恢复HttpSession对象中的每个属性对象。所以存储在HttpSession对象中的每个属性对象必须实现Serializable接口

Session的持久化的作用：

1.提高服务器内存的利用率，保证那些暂停活动的客户端在会话超时之前继续原来的会话

2.在多台web服务器协同对外提供服务的集群系统中，使用Session的持久化技术，某台服务器可以将其中发生改变的Session对象复制给其他服务器。保证了在某台服务器停止工作后可以由其他服务器来接替它与客户端的会话

3.在一个web应用程序重启时，服务器也会持久化该应用程序中所有HttpSession对象，保证客户端的会话活动仍可以继续。

Tomcat使用Session Manager 类来管理Session的持久化，他提供了两个SessionManager类

org.apache.catalina.session.StandardManager

org.apache.catalina.session.PersistentManager

StandardManager是tomcat默认使用的，在web应用程序关闭时，对内存中的所有HttpSession对象进行持久化，把他们保存到文件系统中。默认的存储文件为：

/work/Catalina/<主机名>/<应用程序名>/sessions.ser

PersistentManager比StandardManager更为灵活，只要某个设备提供了实现org.apache.catalina.Store接口的驱动类，PersistentManager就可以将HttpSession对象保存到该设备

转：http://xiaolongfeixiang.iteye.com/blog/560800

session 持久化问题(重启服务器session 仍然存在)

关于在线人数统计，大都使用SessionListener监听器实现。

 

SessionListener 触发源： 

1、Session Create 时

2、Session timeout 时

3、显式调用session的invalidate方法 时

4、在Tomcat设置Session持久化为FALSE的情况下，Tomcat关闭时，触发Session destroy事件

 

5、在Tomcat设置Session持久化为TRUE的情况下，Tomcat重启后，检测到Session超时时，触发Session destroy事件（可归入第2中情况中）

如何Tomcat  Session持久化配置？ 

在默认的情况下，Tomcat6是提供了这项功能的。请查看$TOMCAT_HOME$/conf/context.xml。在大概24行，你会看到注释：

 

Xml代码  

1. <!-- Uncomment this to disable session persistence across Tomcat restarts -->  
2. <!-- 
3. <Manager pathname="" /> 
4. -->  

 

 

这说明默认的Tomcat是支持Session持久化的。当然，取消注释也就取消了这个功能。

 

Session持久化&不持久化

如果Tomcat配置为Session的不持久化，在Tomcat关闭时，会自动触发Session destroy事件。

如果Tomcat配置为Session的持久化，在Tomcat关闭时，不会触发Session destroy事件。而是将每个Session中内容写入到文件中。当Tomcat再次启动时，会读取该参数，并且验证Session是否TimeOut（但是这个验证似乎有点延迟，大概几秒钟吧。如果检测到超时，则Tomcat会自动触发Session Destroy事件）。


失败案例分析： 

最近在分析一个其他人写的应用中，发现在线人数出现负数的情况。原因是没有修改Tomcat的默认配置，因此Session的持久化功能是开启的。当Tomcat重启后，由于在线人数是Listener中的Static常量，所以重启后会归零。重启后，如果触发了Session Destroy事件，那么就会出现在线人数为负的情况。

但是，重启后用户的什么操作会触发Session Destroy事件呢？ 

首先，1个大前提是用户的浏览器在Tomcat重启的间隔都一直存在，且未进行其他操作。（很简单，如果在重启期间，进行任何操作的话，肯定会看到“服务器无法响应”的错误信息，自然就离开了。也就不会有以后了。。）

然后，分2种情况：

情形1： 如果Tomcat关闭的时间大于Session的超时时间。Tomcat会自动地触发Session Destroy事件。上面已经说了，这个“自动”是有延迟的。如果用户进行任何操作，都会立即触发Session Destroy事件。

情形2：如果Tomcat的关闭时间小于Session的超时时间，那么用户点击“注销”等类似的注销功能、或者Session超时，就会触发Session Destroy事件。

解决的办法： 

方案1：关闭Tomcat Session 持久化的功能。取消那句注释即可。

方案2：将在线人数存放在数据库中，每次改变在线人数，都要访问数据库。（加重了数据库访问量）