最近在学Servlet跟Jsp,所以找了孙卫琴的《Tomcat与Java Web开发技术详解》来看。此前学se的时候并没看过这个作者的书,只是听过这个作者的大名,所以学Java EE了,听说这边书不错,就拿来看下。现在看了近一半,却发现这本书没期待中的好。
唠叨就说到这了。说重点:
昨晚看书的时候,看到了持久化会话这一节。Tomcat 的会话管理包括两种。StandardManager跟PersistentManager。
[b]StandardManager[/b]
StandardManager是默认的会话管理器。当Tomcat终止获知单个Web应用被终止时,会对杯终止的Web应用的HttpSession对象进行持久化,然后生成以SESSIONS.ser为名的文件,保存到tomcat目录work里面对应app名里面。重启的时候,会激活被持久化的HttpSession,这时对应的SESSIONS.ser文件也会被删除。
[b]PersistentManager[/b]
PersistentManager与StandardManager不同,它把HttpSession对象用Store保存。Tomcat中Store分为两种:FileStore,JDBCStore。
FileStore讲HttpSession对象保存在一个文件名为SessionID,后缀名为.session的文件中。默认的保存目录为tomcat目录work里面对应app名里面(跟StandardManager一样)。配置的方法为:在appname/META-INF/下创建一个context.xml文件。文件内容为:
[code=XML]<Context reloadable="true">
<Manager className="org.apache.catalina.session.PersistentManager"
saveOnRestart="true"
maxActiveSession="10"
minIdleSwap="60"
maxIdleSwap="120"
maxIdleBackup="180"
maxIncativeInterval="300">
<Store className="org.apache.catalina.session.FileStore" directory="mydir"/>
</Manager>
</Context>[/code]
其中的个个属性我就不多说了。按照此方法,我重启Tomcat,进行测试。测试用的是书中一个登陆app。理论上在用tomcat manager关闭app后,对应的Tomcat work目录中对应的appname里面应该有SessionID.session文件的。可是试了几次之后还是发现对应的文件夹里只有SESSIONS.ser文件。开始以为是得在里面创建相应的directory文件夹(即mydir)文件夹,所以又试了几次,还是不行。觉得是context.xml里面的内容有写错,所以有查了一下,删除了Manager的一些属性,只留下className属性。试了一下还是不行。(在这有个小疑问想弱弱地问下各位。如果context.xml里面有错误的话,tomcat有没有相关提示的)上网搜了一下Tomcat FileStore还有Persistent,没什么进展。郁闷了一段时间,这问题在心里纠结了好一阵(我相信各位在遇到个别问题的时候也有这种状况),无聊就在tomcat目录里面乱翻。无意中在tomcat目录的conf\Catalina\下发现了之前写的一些实例的appname对应的xml文件,打开来看,发现与对应app里面的META-INF里面的context.xml文件内容一样。可就是没发现之前那个测试用的app对应的文件。所以就找了了另外一个app里面(以下称为app2)的context.xml文件,在里面改了一下,此时的context.xml文件里面已经包含错误的属性了。重启Tomcat,访问app2里面访问数据库的jsp页面(之前在context.xml中配置了数据库连接的相关信息),居然没发生错误,-_-!...(好神奇)。再回去看context.xml文件,里面确实是有错的。重启Tomcat数次,照样正常。回去看conf\Catalina\下对应的文件,居然是之前正确的文件(到这我真想说一句¥#%@#*)。-_-.之后我吧里面的app2.xml文件删了,重启Tomcat,访问,终于出错了,大喜(出错反而开心,哎。。。)此时再去看conf里面的文件,终于更新了。这时我才确定每个[color=#FF0000]对应的app里面的context.xml文件,都会以appname的形式被更新到conf里面[/color]。(此后在网上搜索后得以确认,(T_T...菜鸟就是菜鸟))。所以我索性在conf里面直接创建对应的appname.xml文件(之前的都被我一气之下删了),重启Tomcat,以之前的方法测试第一个app,这次终于在对应文件夹里出现了sessionID.session文件了。呼呼。。。之后上网搜索,Tomcat更新context.xml的问题,搜索到的相关问题真少。
不过可以确认的是,在你自更新完context.xml文件后,Tomcat并没有自动更新对应的conf里面的文件。要更新conf里面的文件,就得删除appname.xml文件再重启Tomcat,此时才会更新。(各位如果有什么好的方法,可以跟我提下)
后来总结一下测试出错的原因,有可能的是刚开始context.xml里面有错误,所以conf里面没有对应的文件,不过也有可能是context.xml文件是正确的,可是Tomcat并没有把它加载到conf里面。(因为context.xml文件我检查过好几次了T_T)不知这种情况是否存在。?
唠叨就说到这了。说重点:
昨晚看书的时候,看到了持久化会话这一节。Tomcat 的会话管理包括两种。StandardManager跟PersistentManager。
[b]StandardManager[/b]
StandardManager是默认的会话管理器。当Tomcat终止获知单个Web应用被终止时,会对杯终止的Web应用的HttpSession对象进行持久化,然后生成以SESSIONS.ser为名的文件,保存到tomcat目录work里面对应app名里面。重启的时候,会激活被持久化的HttpSession,这时对应的SESSIONS.ser文件也会被删除。
[b]PersistentManager[/b]
PersistentManager与StandardManager不同,它把HttpSession对象用Store保存。Tomcat中Store分为两种:FileStore,JDBCStore。
FileStore讲HttpSession对象保存在一个文件名为SessionID,后缀名为.session的文件中。默认的保存目录为tomcat目录work里面对应app名里面(跟StandardManager一样)。配置的方法为:在appname/META-INF/下创建一个context.xml文件。文件内容为:
[code=XML]<Context reloadable="true">
<Manager className="org.apache.catalina.session.PersistentManager"
saveOnRestart="true"
maxActiveSession="10"
minIdleSwap="60"
maxIdleSwap="120"
maxIdleBackup="180"
maxIncativeInterval="300">
<Store className="org.apache.catalina.session.FileStore" directory="mydir"/>
</Manager>
</Context>[/code]
其中的个个属性我就不多说了。按照此方法,我重启Tomcat,进行测试。测试用的是书中一个登陆app。理论上在用tomcat manager关闭app后,对应的Tomcat work目录中对应的appname里面应该有SessionID.session文件的。可是试了几次之后还是发现对应的文件夹里只有SESSIONS.ser文件。开始以为是得在里面创建相应的directory文件夹(即mydir)文件夹,所以又试了几次,还是不行。觉得是context.xml里面的内容有写错,所以有查了一下,删除了Manager的一些属性,只留下className属性。试了一下还是不行。(在这有个小疑问想弱弱地问下各位。如果context.xml里面有错误的话,tomcat有没有相关提示的)上网搜了一下Tomcat FileStore还有Persistent,没什么进展。郁闷了一段时间,这问题在心里纠结了好一阵(我相信各位在遇到个别问题的时候也有这种状况),无聊就在tomcat目录里面乱翻。无意中在tomcat目录的conf\Catalina\下发现了之前写的一些实例的appname对应的xml文件,打开来看,发现与对应app里面的META-INF里面的context.xml文件内容一样。可就是没发现之前那个测试用的app对应的文件。所以就找了了另外一个app里面(以下称为app2)的context.xml文件,在里面改了一下,此时的context.xml文件里面已经包含错误的属性了。重启Tomcat,访问app2里面访问数据库的jsp页面(之前在context.xml中配置了数据库连接的相关信息),居然没发生错误,-_-!...(好神奇)。再回去看context.xml文件,里面确实是有错的。重启Tomcat数次,照样正常。回去看conf\Catalina\下对应的文件,居然是之前正确的文件(到这我真想说一句¥#%@#*)。-_-.之后我吧里面的app2.xml文件删了,重启Tomcat,访问,终于出错了,大喜(出错反而开心,哎。。。)此时再去看conf里面的文件,终于更新了。这时我才确定每个[color=#FF0000]对应的app里面的context.xml文件,都会以appname的形式被更新到conf里面[/color]。(此后在网上搜索后得以确认,(T_T...菜鸟就是菜鸟))。所以我索性在conf里面直接创建对应的appname.xml文件(之前的都被我一气之下删了),重启Tomcat,以之前的方法测试第一个app,这次终于在对应文件夹里出现了sessionID.session文件了。呼呼。。。之后上网搜索,Tomcat更新context.xml的问题,搜索到的相关问题真少。
不过可以确认的是,在你自更新完context.xml文件后,Tomcat并没有自动更新对应的conf里面的文件。要更新conf里面的文件,就得删除appname.xml文件再重启Tomcat,此时才会更新。(各位如果有什么好的方法,可以跟我提下)
后来总结一下测试出错的原因,有可能的是刚开始context.xml里面有错误,所以conf里面没有对应的文件,不过也有可能是context.xml文件是正确的,可是Tomcat并没有把它加载到conf里面。(因为context.xml文件我检查过好几次了T_T)不知这种情况是否存在。?