Tomcat 5的Session Persistent问题

tomcat 5的新功能，服务复位后自动恢复session。

如果要禁用这一特性，到apache-tomcat/conf/Catalina/localhost目录下找到webapp同名的xml，修改成：

<Context path="..." reloadable="..." docBase="..." workDir="...">
  <Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="false"/>
</Context>

 

Tomcat服务器配置参考

Manager组件

概述

Manger元素代表用来产生，维护HTTP session的session manager。

Manager元素可以嵌套在Context组件中。如果不包含它，会自动创建一个缺省的Manager配置，这对大多数需求都是足够的。

 

属性

公共属性

所有Manager的实现支持如下属性：

属性 描述 className

实现的Java类名。这个类必须实现org.apache.catalina.Manager接口。如果没有指定，使用标准值。

distributable

在分布式应用中，如果想加上Servlet Specification中描述的限制，设为true。这意味着所有的session属性必须实现java.io.Serializable接口。如果不想加上这些限制，设为false

注意：根据/web-inf/web.xml中是否存在<distributable>元素，这个属性值自动继承；

标准实现

 

 

Tomcat为Manger提供了两个标准实现。缺省的实现存储活动的session，可选的实现存储被交换出来的活动session（另外还存储tomcat重启前后的session)，存储的位置由嵌套的Store元素定义。

标准的Manager实现

Manger的标准实现是org.apache.catalina.session.StandardManger。它支持如下的附加属性：

属性 描述 algorithm

用于计算session标识符的消息摘要算法。这个值必须被java.security.MessageDigest类支持。如果没有指定，缺省值是“MD5”

checkInterval

检查session是否过期的时间间隔，以秒为单位，缺省值是60秒

debug 与Manager相关的Logger记录的调试信息的详细程度，数字越大，输出越详细。如果没有指定，缺省值为0。 entropy

在创建session标识符中随机数发生器的种子。为字符串值。如果没有指定，计算一个不完全有用的值。在安全要求很高的环境中，应该指定一个长的字符串。

maxActiveSessions

产生的最大活动session数。如果为－1，说明没有限制。

pathname

如果可能的话，当应用重启时，用于保存session状态的文件的绝对或者相对路径。缺省为“SESSIONS.ser”。参考Restart Persistence，以得到更多信息

randomClass

实现java.util.Random的Java类名。如果没有指定，缺省为java.security.SecureRandom

Persisten Manager实现

警告－这个实现还没有经过细致的测试，只能用于实验用途。

Manger的persistent实现是org.apache.catalina.session.PersistentManager。除了通常的创建和删除session以外，PersistentManger还能够将空闲的活动session交换到永久的存贮介质上面。当tomcat正常重启时，还可以将session保存下来。实际使用的存储机制由嵌套的store元素定义。使用PersistentManager时，store元素必须定义。

Manager的这个实现支持如下的附加属性:

 

 

属性 描述 algorithm

产生session identifier的消息摘要算法的名称。这个值必须被java.security.MessageDigest类支持。如果没有指定，缺省值为“MD5”。

checkInterval 检查session是否过期的时间间隔，以秒为单位，缺省值为60秒。 className 实现的Java类名。这个类必须实现 org.apache.catalina.Manager接口。对于persistent manager实现，必须指定为org.apache.catalina.session.PersistentManager。 debug

与Manager相关联的Logger记录信息的详细程度。数字越大，输出越详细。如果不指定，缺省值为0。

entropy

在创建session标识符中随机数发生器的种子。为字符串值。如果没有指定，计算一个不完全有用的值。在安全要求很高的环境中，应该指定一个长的字符串。

maxActiveSessions

产生的最大活动session数。如果为－1，说明没有限制。

maxIdleBackup

自上次访问某个session到这个session可以被保存到存储介质上的时间间隔。以秒为单位，如果为－1，则disable这个特征。缺省情况下，这个特征是disable的。

maxIdleSwap

自上次访问某个session到session应该被保存到存储介质上，并从服务器的内存中交换出来之间的时间间隔。如果为－1，则disable这个特征。如果使能了这个特征，指定值应该大于或者等于maxIdleBackup。缺省情况下这个特征是disable的。

minIdleSwap

自上次访问某个session到session可以被保存到存储介质上，并从服务器的内存中交换出来之间的时间间隔。如果为-1，说明可以在任何时间交换出来。指定值应该小于maxIdleSwap。缺省情况下这个特征是disable的。

randomClass

实现java.util.Random的Java类名。如果没有指定，缺省为java.security.SecureRandom

saveOnRestart

当Tomcat关闭的时候，是否应该保存所有的session？Tomcat重启（或者应用重新载入）后是否应该恢复所有的session。缺省情况下为true。

为了成功使用PersistentManager，你必须嵌套一个<Store>元素，如下所述。

嵌套元素

标准Manager实现

如果使用Standard Manager实现，<Manager>元素中不需要嵌套任何元素

Persistent Manager实现

如果使用Persistent Manager实现，你必须在<Manager>元素中嵌套一个<Store>元素。<Store> 元素定义了数据存储的特性。目前<Store>元素有两个实现，下面描述了它们的特征。

 

基于文件的存储

基于文件的存储实现将交换出来的session存储在指定目录下的单个的文件中（根据session identifier命名）。因此，当活动session数目增加时，可能会碰到扩展性的问题，这种方法应该主要用在实验系统中。

为了配置基于文件的存储，在<Manager>元素中嵌套一个<store>元素，并具有如下属性：

属性 描述 checkInterval

检查当前被交换出来的session是否过期的时间间隔，缺省值为60秒。

className 实现的Java类名。这个类必须实现org.apache.catalina.Store接口。使用基于文件的存储时，必须将这个属性指定为org.apache.catalina.session.FileStore. debug

与Store元素相关联的Logger的调试信息的详细程度。数字越大，输出越详细。如果没有指定，缺省值为0。

directory

用来存储单个session文件的目录，可以是绝对或者相对路径（相对于这个web应用的临时工作目录）。如果没有指定，使用container指定的临时工作目录。

 

基于JDBC的存储

基于JDBC的存储实现将交换出来的session存储在预先配置好的数据库表中，每一行存储一个session。如果有大量的session需要交换出来，这种实现比基于文件的存储性能要好。

为了使用基于JDBC的存储，在<Manager>元素中嵌套一个<Store>元素，并配置如下属性：

属性 描述 checkInterval

检查当前被交换出来的session是否过期的时间间隔，缺省值为60秒。

className

实现的Java类名。该类必须实现org.apache.catalina.Stroe接口。为了使用基于JDBC的存储，这个指必须指定为org.apache.catalina.session.JDBCStore.

connectionURL

建立数据库连接的URL，传递给JDBC驱动。

debug

与Store元素相关联的Logger的调试信息的详细程度。数字越大，输出越详细。如果没有指定，缺省值为0。

driverName

使用的JDBC驱动的Java类名

sessionAppCol session表中的数据库列名，包含Engine，Host和Web应用上下文的名称，格式为/Engine/Host/Context sessionDataCol

session表中的数据库列名，包含交换出来的session的所有属性序列化以后的形式。列类型必须能够接受二进制对象（称作BLOB）

sessionIdCol

Session表中的数据库列名，包含交换出来的session的session标识符。该列必须接受字符串数据，并且至少要能装下session标识符的所有字符（通常为32）

sessionLastAccessedCol

session表中的数据库列名，包含session的lastAccessedTime属性。该列必须接受Java长整型数据（64bits）

 

 

sessionMaxInactiveCol session表中的数据库列名，包含session的maxInactiveInterval属性。该列必须接受Java整型数据（32bits） sessionTable

用来存储交换出来的session的表名。这个表至少必须包含上面列出的列。

 

sessionValidCol

session表中的列名，包含一个标志，表名交换出来的session是否有效。该列必须接受单个字符。

在第一次使用基于JDBC的存储之前，必须创建用来存储session的表。具体的SQL命令取决于你使用的数据库，但一般来说，具有象下面的格式：

create table tomcat_sessions (  session_id     varchar(100) not null primary key,  valid_session  char(1) not null,  max_inactive   int not null,  last_access    bigint not null,  app_name       varchar(255),  session_data   mediumblob,  KEY kapp_name(app_name));

为了使基于JDBC的存储成功地连接到你的数据库，JDBC驱动对Tomcat的内置class loader必须是可见的。一般来说，这意味着你必须把包含驱动的JAR文件放在$CATALINA_HOME/server/lib下面（如果你的应用不需要使用JDBC驱动）或者放在$CATALINA_HOME/common/lib目录下面（如果希望将驱动和web应用共享）

专有特征

Restart Persistence

每当Catalina被正常关闭后重新启动，或者应用被重新载入，标准的Manager实现会尝试将目前所有的活动session序列化到一个磁盘文件中，通过pathname属性。当应用完成重载以后，所有存储的session被deserialized，激活（假定session同时还没有过期）；

为了成功恢复session属性的状态，所有的属性必须实现java.io.Serializable接口。通过在/WEB-INF/web.xml中包含<distributable>元素，可以要求Manager加上这个限制。