转载自：http://blog.csdn.net/ever_legend_/article/details/49421605
问题描述
同一台服务器, 安装两个tomcat ,端口不一样, 姑且分别称为tomcat1 和 tomcat2, 在两个tomcat下分别都部署了A和B两个项目
-
同一个浏览器访问同一个tomcat的不同项目: 访问tomcat1(tomcat2)的A并登陆, 再访问tomcat1(tomcat2)的B , 测试结果两个项目的访问互不干扰;
-
同一个浏览器访问不同tomcat的不同项目: 访问tomcat1的A并登陆, 再访问tomcat2的B, 测试结果两个项目的访问互补干扰;
-
同一个浏览器访问不同tomcat的相同项目: 访问tomcat1的A(B)项目并登陆, 再访问tomcat2的A(B), 测试结果访问tomcat2的A(B)项目之后, 造成了sessionID的覆盖,使之前登录过的tomcat1的A(B)项目的session失效;
原因分析
同一个浏览器, 访问两个tomcat服务, 项目名,ip都是一样,唯一不一样的是端口, 以下解释纯属个人臆测:
浏览器刚打开时, 访问tomcat1, 这个时候tomcat给浏览器生成并返回了一个JSESSIONID, 同时创建了一个session, 此时JSESSIONID成为了用户访问Tomcat 1 会话识别标志, 当我再新建一个窗口,访问tomcat2的另外一个同名项目(不同端口)时, 浏览器的request cookies ,默认竟然是有JSESSIONID的, 同时又反回了一个新的JSESSIONID, 说明服务端tomcat2不存在这个JSESSIONID,所以重新创建了一个, 作为和用户会话的依据, 然后,再访问tomcat1时, 同样的一幕出现了, 也是用了之前tomcat2返回给用户的JSESSIONID作为新的request cookies的JSESSIONID ,用作和服务端会话的依据, response cookies 又返回了一个新的JSESSIONID, 如此反复, 说明用户在同一个浏览器请求这个两个项目的时候, 本地的存储的JSESSIONID是不断相互覆盖的, 造成相互覆盖的原因我估计是, JSESSIONID存储的区域和项目域名, 项目名有关, 导致访问后一个项目的时候直接用了之前那个已经访问过了的项目存储在本地会话标识(JSESSIONID), 然后用这个JSESSIONID去请求, 发现tomcat2里面根本就没有JSESSIONID对应的session会话, 所以tomcat2重新生成了一个JSESSIONID返回客户端浏览器, tomcat1 再次请求时, 就会用了新返回的JSESSIONID作为请求的JSESSIONID, 自然在tomcat1也找不到这个对应的session会话了;
解决方案
解决方案,很简单, tomcat6以上, 直接改下conf文件下的context.xml的 context标签, 给每个tomcat的
SessionCookieName=”JSESSIONID_1”设置一个名字(默认是JSESSIONID)