session,cookie,丢失，不能保存；apache,weblogic

娇w兴

　　....
　　http://blog.iyunv.com/xgx1985xgx/article/details/6586690
　　之前做一个页面时发现如果：A站iframe引用B站的页面时（A，B不在同一台服务器），如果在这个Iframe中B的页面做了跳转，当用IE浏览的时候会导致server 的session丢失，原因是IE的保护机制禁止将iframe中得到的sid传递给下一个页面。
　　解决方法比较简单：在B被引用的页面上添加JSP代码：
　　
　　






[html] view plaincopy

http://static.blog.iyunv.com/scripts/ZeroClipboard/ZeroClipboard.swf

•    
  

[html] view plaincopy

http://static.blog.iyunv.com/scripts/ZeroClipboard/ZeroClipboard.swf

• 1.页面里的COOKIE不能是浏览器进程的COOKIE(包括验证票和不设置超时时间的COOKIE),否则跨域会取不到.这点做跨域COOKIE的人比较少提到.不过实际上留意下几家大学做的方案,有细微的提到他们的验证模块里的COOKIE是有设置超时时间的.2.当利用IFRAME时,记得要在相应的动态页的页头添加一下P3P的信息,否则IE会自觉的把IFRAME框里的COOKIE给阻止掉,产生问题.本身不保存自然就取不到了.这个其实是FRAMESET和COOKIE的问题,用FRAME或者IFRAME都会遇到.3.测试时输出TRACE,会减少很多测试的工作量.只需要设置 P3P HTTP Header，在隐含 iframe 里面跨域设置 cookie 就可以成功。他们所用的内容是：P3P: CP='CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR'ASP直接在头部加了头部申明，测试有效。  
  
•   
  
•   
  
• php的话，应该是如下写法：  
  
• header('P3P: CP=CAO PSA OUR');  
  
•   
  
• ASP.NET的话  
  
• 通过在代码上加Response.AddHeader("P3P", "CP=CAO PSA OUR")或者在Window服务中将ASP.NET State Service 启动。  
  
•   
  
• JSP:  
  
• response.setHeader("P3P","CP=CAO PSA OUR")     
  

[html] view plaincopy　　==============================
　　http://liuzidong.iteye.com/blog/1132219
　　参考资料
1 关于WebLogic的Session丢失的问题
http://blog.iyunv.com/DesignLife/article/details/2552186
2 tomcat向weblogic移植出现的问题系列 - session丢失问题
(其中一位网友回答不知是什么意思,要加什么文件)
http://netliving.iteye.com/blog/148485
3 java weblogic session 丢失
http://hi.baidu.com/leftstone/blog/item/3b34a4a19d4d0588471064f0.html
4 weblogic两个domain中jsp相互调用session丢失解决方法
http://www.4ucode.com/Study/Topic/1159787
5 关于WebLogic的Session丢失的问题
http://hi.baidu.com/goylsf/blog/item/d2446677d71e070ab051b98d.html
6 weblogic通过代理插件weblogic.servlet.proxy.HttpProxyServlet跨域访问导致session丢失问题的解决
http://ribbonchen.blog.163.com/blog/static/1183165052011074500877/
7 WebLogic如何设置session超时时间
http://tonyaction.blog.iyunv.com/227462/201900
注意网上有很多的Webloigc不是最新的配置
位于WEB-INF/WebLogic.xml配置如下：






Java代码 http://liuzidong.iteye.com/javascripts/syntaxhighlighter/clipboard_new.swf

•    
  
•    
  
•       
  
•         true  
  
•       
  
•     /  
  
•       
  
•          
  
•          
  
•         JSESSIONID1  
  
•       
  
•   
  

　　
一 WebLogic设置Session超时
1 web.xml
设置WEB应用程序描述符web.xml里的元素。这个值以分钟为
单位，并覆盖weblogic.xml中的TimeoutSecs属性






Java代码 http://liuzidong.iteye.com/javascripts/syntaxhighlighter/clipboard_new.swf

•   
  
•     30  
  
•   
  

　　
此例表示Session将在54分钟后过期
当设置为－2，表示将使用在weblogic.xml中设置的
TimeoutSecs这个属性值。
当设置为－1，表示Session将永不过期，而忽略在
weblogic.xml中设置的TimeoutSecs属性值。
该属性值可以通过console控制台来设置
在weblgoic的console中：xxDomain－>Servers->xxServer->Protocols->HTTP 中有一个关于Post Timeout的配置，但这个参数一般使用默认值即可
一般是通过Services-->JDBC-->Connection Pools-->MyConnection(你所建立的连接池名)－－>Configration-->Connections 里的Inactive Connection Timeout这个参数来设置的，默认的为0，表示连接时间无限长。你可以设一个时间值，连接超过这个时间值，它会把连接强制放回连接池






Java代码 http://liuzidong.iteye.com/javascripts/syntaxhighlighter/clipboard_new.swf

•   
  

　　
是否IdleConnectionTimeout参数
2 weblogic.xml
设置WebLogic特有部署描述符weblogic.xml的元素的
TimeoutSecs属性。这个值以秒为单位






Java代码 http://liuzidong.iteye.com/javascripts/syntaxhighlighter/clipboard_new.swf

•   
  
•          
  
•        7200         
  
•   
  

　　

二 防止Webloigic下的iframe的Session失效
请在Weblogic.xml添加如下代码






Java代码 http://liuzidong.iteye.com/javascripts/syntaxhighlighter/clipboard_new.swf

•       
  
•         JSESSIONID1  
  
•   
  

　　
原来session在服务器端生成后分配的sessionID在客户端的保存方式是个cookie，它的生命周期在浏览器关闭后就会结束，而这个cookie的名字如果不特别设置，weblogic会以默认的名称“JSESSIONID”来设置这个cookie的名称，我两个应用的的session cookie名字都没有设置，客户端在第一次通过应用A请求代理转发到应用B时，应用B返回的同名session cookie覆盖了客户端原本的应用A的session cookie，所以导致了应用A session的丢失。
解决方法是，在应用B的weblogic.xml中的session descriptor标记中添加session cookie的名称设置，使其区别于A应用的session cookie名称.其中的cookie-name可以重命名!解决在iframe中进行跨域访问时session丢失的问题
附件有：weblogic-web-app.xsd
　　==============================
　　http://bbs.phpchina.com/thread-90724-1-1.html
　　看看你的浏览器设置的是否支持Cookies，还有Apache用的时间与本机时间时区不同造成时差也会使Cookies丢失。
　　==========================
　　
　　session和cookie是网站浏览中较为常见的两个概念，也是比较难以辨析的两个概念，但它们在点击流及基于用户浏览行为的网站分析中却相当关键。基于网上一些文章和资料的参阅，及作者个人的应用体会，对这两个概念做一个简单的阐述和辨析，希望能与大家共同探讨下。
　　session和cookie的最大区别在于session是保存在服务端的内存里面，而cookie保存于浏览器或客户端文件里面；session是基于访问的进程，记录了一个访问的开始到结束，当浏览器或进程关闭之后，session也就“消失”了，而cookie更多地被用于标识用户，它可以是长久的，用于用户跟踪和识别唯一用户（Unique Visitor）。

关于session
　　session被用于表示一个持续的连接状态，在网站访问中一般指代客户端浏览器的进程从开启到结束的过程。session其实就是网站分析的访问（visits）度量，表示一个访问的过程。

　　session的常见实现形式是会话cookie（session cookie），即未设置过期时间的cookie，这个cookie的默认生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。实现机制是当用户发起一个请求的时候，服务器会检查该请求中是否包含sessionid，如果未包含，则系统会创造一个名为JSESSIONID的输出cookie返回给浏览器(只放入内存，并不存在硬盘中)，并将其以HashTable的形式写到服务器的内存里面；当已经包含sessionid是，服务端会检查找到与该session相匹配的信息，如果存在则直接使用该sessionid，若不存在则重新生成新的session。这里需要注意的是session始终是有服务端创建的，并非浏览器自己生成的。
　　但是浏览器的cookie被禁止后session就需要用get方法的URL重写的机制或使用POST方法提交隐藏表单的形式来实现。
　　这里有一个很关键性的注意点，即session失效时间的设置，这里要分两方面来看：浏览器端和服务端。对于浏览器端而言，session与访问进程直接相关，当浏览器被关闭时，session也随之消失；而服务器端的session失效时间一般是人为设置的，目的是能定期地释放内存空间，减小服务器压力，一般的设置为当会话处于非活动状态达20或30分钟时清除该session，所以浏览器端和服务端的session并非同时消失的，session的中断也并不一定意味着用户一定离开了该网站。目前Google Analytics和Omniture都定义当间隔30分钟没有动作时，算作一次访问结束，所以上图中session的最后一步不只是离开，也有可能是静止、休眠或者发呆的状态。
　　还有一点需要注意，就是现在的浏览器好像趋向于多进程的session共享，即通过多个标签或页面打开多个进程访问同一网站时共享一个session cookie，只有当浏览器被关闭时才会被清除，也就是你有可能在标签中关闭了该网站，但只要浏览器未被关闭并且在服务器端的session未失效前重新开启该网站，那么就还是使用原session进行浏览；而某些浏览器在打开多页面时也可能建立独立的session，IE8、Chrome默认都是共享session的，在IE8中可以通过菜单栏中的文件->新建会话来建立独立session的浏览页面。

关于cookie

　　cookie 是一小段文本信息，伴随着用户请求和页面在Web服务器和浏览器之间传递。用户每次访问站点时，Web应用程序都可以读取cookie包含的信息。
　　session的实现机制里面已经介绍了常见的方法是使用会话cookie（session cookie）的方式，而平常所说的cookie主要指的是另一类cookie——持久cookie（persistent cookies）。持久cookie是指存放于客户端硬盘中的cookie信息（设置了一定的有效期限），当用户访问某网站时，浏览器就会在本地硬盘上查找与该网站相关联的cookie。如果该cookie 存在，浏览器就将它与页面请求一起通过HTTP报头信息发送到您的站点，然后在系统会比对cookie中各属性和值是否与存放在服务器端的信息一致，并根据比对结果确定用户为“初访者”或者“老客户”。
　　持久cookie一般会保存用户的用户ID，该信息在用户注册或第一次登录的时候由服务器生成包含域名及相关信息的cookie发送并存放到客户端的硬盘文件上，并设置cookie的过期时间，以便于实现用户的自动登录和网站内容自定义。
　　Apache自带的mod_usertrack模块可以在用户首次来到当前网站的时候给用户种下一个唯一的cookie（较长时间过期），这个cookie是用户首次来当前网站的IP地址加上一个随机字符串组成的。同时在自定义WEB日志中在最后增加%{cookie}n字段可以实现cookie在apache日志中的输出，用于数据统计与用户跟踪。
　　
　　
　　http://bbs.phpchina.com/thread-243469-1-1.html
　　


这些都是基础知识，不过有必要做深入了解。先简单介绍一下。

二者的定义：

当你在浏览网站的时候，WEB 服务器会先送一小小资料放在你的计算机上，Cookie 会帮你在网站上所打的文字或是一些选择，

都纪录下来。当下次你再光临同一个网站，WEB 服务器会先看看有没有它上次留下的 Cookie 资料，有的话，就会依据 Cookie

里的内容来判断使用者，送出特定的网页内容给你。 Cookie 的使用很普遍，许多有提供个人化服务的网站，都是利用 Cookie

来辨认使用者，以方便送出使用者量身定做的内容，像是 Web 接口的免费 email 网站，都要用到 Cookie。


具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。

同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制

来达到保存标识的目的，但实际上它还有其他选择。

cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示

浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用

是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围

大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。
cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这

个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。

会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie

保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏

览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式

session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

          当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识

（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来

使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相

关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应

中返回给客户端保存。保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给

服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时

仍然能够把session id传递回服务器。

经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器

会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如：




实际上这种技术可以简单的用对action应用URL重写来代替。

cookie 和session 的区别：

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
   考虑到安全应当使用session

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
   考虑到减轻服务器性能方面，应当使用COOKIE

4、单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。

5、所以个人建议：
   将登陆信息等重要信息存放为SESSION
   其他信息如果需要保留，可以放在COOKIE中





http://bbs.phpchina.com/thread-168890-1-1.html

从网络服务器观点看，所有HTTP请求都独立于先前请求。就是说每一个HTTP响应完全依赖于相应请求中包含的信息，而为了客服克服了HTTP的这些限制并允许网络客户端及服务器端维护请求间的关系，那么就需要一种状态管理机制。   Cookie机制采用的是在客户端保持状态的方案。它是在用户端的会话状态的存贮机制，他需要用户打开客户端的cookie支持。Cookie 的作用就是为了解决HTTP协议无状态的缺陷所作的努力。Cookie是服务器请求客户端在本地机器上存储的小段文本，并随每一个请求发送至同一个服务器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie规范。网络服务器也可以通过扩展HTTP协议来实现的向客户端分发cookie，服务器通过在HTTP的响应头中加上一行特殊的指示 (即Set-Cookie属性)以提示浏览器按照指示生成相应的cookie，并存放在内存(或文件)中以供使用。   而Session机制采用的是一种在客户端与服务器之间保持状态的解决方案。Session将信息保存在服务器上，用一个标识（session id）来区分是客户端的请求所关联的session。该标识是在session被创建的时候生成并传递给客户端的，并通过用户的浏览器在访问的时候返回给服务器。由于需要传递和保存这样一个标识，所以session机制可能需要借助于cookie机制来达到这个的目的，而当客户端是可以禁用cookie机制的，所以这个标识也可能通过其他的方式来返回给服务器。

http://blog.iyunv.com/DesignLife/article/details/2552186



　　最近在把Tomcat下的程序迁移到Weblogic上的时候遇到了问题，我的程序中有一个过滤器，这个过滤器主要用来检查当前用户访问的资源是否需要认证，如果需要认证并且没有认证的话，则跳转到另外一个认证服务器上去做认证，认证通过后，再跳转回当前服务器继续访问请求的资源。这个过滤器在Tomcat下运行的很正常，但是迁移到Weblogic上的时候就出现页面乱跳转的现象，因为对程序没有做任何改动，所以怀疑是Tomcat和Weblogic这两个不同的Web容器在处理方式上有差别，于是就在过滤器中加入了一些输出信息，通过观察发现了用户的sessionid在Weblogic上跳转前后发生了变化，而在Tomcat上跳转前后则不会有任何变化。页面的跳转是通过response.sendRedirect("xxx.jsp")来实现的，因此怀疑Weblogic在这个方法的处理上跟Tomcat上不同而导致错误产生（很愚蠢的怀疑，这也导致我在查找问题的方向上出现了错误），一直认为可以通过修改Weblogic的weblogic.xml这个文件来解决，在网上搜了很多，也在看了一天weblogic的资料，都没有解决。后来无意中发现了一个问题，我如果访问的资源都是本地服务器上的，那么去认证之后就不会报错，如果是其他服务器的（其他服务器也使用同一个认证服务器做认证）则会出现上述问题，对cookie做了进一步的跟踪，发现cookie里面的jsessionid在访问了其他服务器之后就被修改了，也就是原来的jsessionid不见了。同样的事情，在tomcat上就不会出现（到现在我还认为是Tomcat和Weblogic的差别）。在Google上搜索了Ｎ遍无果之后，在Baidu上终于结果了，有人遇到过跟我相同的问题，这个问题并不是Tomcat和Weblogic的差别引起的，我在查找问题原因的时候忽略了一个细节，也就是迁移到的Weblogic服务器上，和另外几个服务器(包括认证服务器)都在同一个ＩＰ地址的不同端口下，也就是在同一个域下，而这应该就是问题的所在。具体的细节我还没有搞清楚，但应该是访问了同一个服务器而导致了jsessionid发生了覆盖，解决方法很简单
　　如下：两个web使用不同的sessionid来标识，如第一个web使用jsessionid1,第二个web使用 jsessionid2就可以了。 直接在每个web程序下配置weblogic.xml
　　
　　        
　　CookieName        
　　JSESSIONID1      
　　   
　　        
　　即将第一个web app的session id标识改为jsessionid1,同理将第二个改为jsessionid2
　　我只是修改了我的服务器上的weblogic，而没有修改其他服务器的，以上问题得到解决了。
　　同样，这也解释了为什么在最开始的时候我发现jsessionid在Tomcat下不变，而在Weblogic上确改变了的问题
　　
　　http://blog.webwlan.net/wordpress/?p=3779
　　
　　我在同一个weblogic下创建了两个domain，部署了两个系统A和B。其中系统A有一个按钮可打开系统B，并自动登录。通过A系统打开B系 统后session会发生无规律丢失的情况。经过两天的研究，baidu，goolge了无数次后找到了一个帖子，里面写了一下方法：
　　这主要是sessionid在影响，你登录第一个web时默认使用jsessionid来记录session id的，放在cookie里 或者url后面，登录第二个时还是默认使用的jsessionid来做的，这样第二个会覆盖第一个jsessionid，所 以表现为session丢失了。
　　解决办法如下：两个web使用不同的sessionid来标识，如第一个web使用jsessionid1,第二个web使用 jsessionid2就可以了。 直接在每个web程序下配置weblogic.xml


CookieName
JSESSIONID1


即将第一个web app的session id标识改为jsessionid1,同理将第二个改为jsessionid2 ，这样你再来做你 的就不会有问题了。
　　
　　http://itindex.net/blog/2010/06/18/1276830937324.html
　　
　　问题描述
集成项目HT实施过程中碰到这样的问题，本次集成是把两个不同的应用集成到同一个页面框架下，部署方式为：
同一个Server ServerName = Server01，同一个Weblogic，分别建立两个Domain，Domain01(port-7001)和Domain02(port-7002)，将应用App1部署在Domain01，将应用App2部署在Domain02，同时启动这两个Domain，如果完全是默认配置，单独访问两个应用是没有问题的，但是在同一个客户端如果访问App1之后再访问APP2会发现App1的Session丢失。
问题分析
客户端在访问App1时，Domain01会在该客户端保留一个名为 JSessionID的Cookie，记录了Domain01的信息，JSessionID为Weblogic cookie-name的默认值，当同一个客户端访问App2时，该客户端Cookie中JSessionID的值被Domain02刷新，此时如果在之前已经打开的IE中继续访问App1会发现Session丢失(JSessionID已经被Domain02刷新！)。
解决方案
第一种方案
在App1和App2的weblogic.xml文件添加如下属性


CookieName
myCookie1


将 的值更改为不同于默认值就可以
如果不添加这个,那么客户端的COOKIE中保存的SESSION ID的对象名字是JSESSIONID,来自同一个SERVER上面的应用可能会造成这个SESSION ID的丢失,因为只要是WEBLOGIC产生的SESSION ID都是保存在这个名字的COOKIE中,这段配置就是把应用中的这个名字换成我们私有的,避免和其它域中的应用产生的JSESSIONID冲突。
第二种方案
访问App1时用IP来访问，访问App2时用域名来访问。
特别注意
如果应用程序部署为Cluster的模式，将无法设定，否则部署时发生错误。
　　http://tonyaction.blog.iyunv.com/227462/201900
　　

WebLogic如何设置session超时时间


1 web.xml

设置WEB应用程序描述符web.xml里的元素。这个值以分钟为
单位，并覆盖weblogic.xml中的TimeoutSecs属性

    54

此例表示Session将在54分钟后过期
当设置为－2，表示将使用在weblogic.xml中设置的
TimeoutSecs这个属性值。
当设置为－1，表示Session将永不过期，而忽略在
weblogic.xml中设置的TimeoutSecs属性值。
该属性值可以通过console控制台来设置
2 weblogic.xml
设置WebLogic特有部署描述符weblogic.xml的元素的
TimeoutSecs属性。这个值以秒为单位

   
      TimeoutSecs
      3600
   

默认值是3600秒
3,jsp中控制
session.setmaxinactiveinterval(7200);
session是默认对象,可以直接引用,单位秒s

4,servlet中控制
httpsession session = request.getsession();
session.setmaxinactiveinterval(7200);
单位秒s
在weblgoic的console中：xxDomain－>Servers->xxServer->Protocols->HTTP 中有一个关于Post Timeout的配置，但这个参数一般使用默认值即可
一般是通过Services-->JDBC-->Connection Pools-->MyConnection(你所建立的连接池名)－－>Configration-->Connections 里的Inactive Connection Timeout这个参数来设置的，默认的为0，表示连接时间无限长。你可以设一个时间值，连接超过这个时间值，它会把连接强制放回连接池

是否IdleConnectionTimeout参数
看连接池中高级选项内的Inactive Connection Timeout和Connection Reserve Timeout时多少， 把这两项设大些试试









http://www.verydemo.com/demo_c167_i12330.html

　　一个服务器上搭建了多个tomcat或者weblogic，端口不一样，同时启动访问时session丢失。如：A，B两个服务，在浏览器中登录访问A后，当前打开的浏览器上在开一个选项卡访问B服务后，回过来点击访问A时session丢失，需要重新登录A才可以访问。经过资料查找，发现问题是因为：IP相同认为是同一个域,接收了B的set-cookie指令,把对应的cookie内容覆盖了,其中包括jsessionid,造成A的session丢失。 如果IP不同,则不会发生这个问题。IP相同的两个session对应的cookie是一样的，而不幸的是sessionID就保存在cookie中，这样先访问A，再访问B的时候，B的sessionid会覆盖A的sessionid。这个事情没办法解决，所以你不要搞两个端口，最好是搞两个IP。原来都是cookie惹的祸，它不会区分端口，造成这多个站点不断的后来的覆盖前面的，从而造成session的丢失。
　　解决方法：
　　方法1：将不同的多个应用服务在不同的虚拟主机中，或者映射不同的IP进行部署。
　　方法2：对应tomcat服务处理方式：修改coocie的名称保证cookie不重复，即jsessionid的不重称，保证ip相同下sessioncookiename域名不同。
　　1、tomcat5修改方法
　　在启动项中增加org.apache.catalina.SESSION_COOKIE_NAME参数

　　linux
JAVA_OPTS=’-Dorg.apache.catalina.SESSION_COOKIE_NAME=yousessionname‘
　　win
set JAVA_OPTS=”-Dorg.apache.catalina.SESSION_COOKIE_NAME=yousessionname“

　　           2、tomcat6和tomcat7修改方法相同
　　       tomcat增加参数对所有Context生效，影响甚大，所以到以后的版本可以就仅针对Context设置了

　　在Context容器标签上增加sessionCookieName参数

　　

          3、weblogic修改方法　　设置各个应用使用不同的cookie-name。
　　weblogic的设置（设置不同的cookie-name）：
         请在WEB-INF\Weblogic.xml添加如下代码
                        
                             JSESSIONID1   
                  
　　
　　
　　http://my.oschina.net/moyuqi/blog/98475
　　
　　使用apache反向代理解决在应用A使用Iframe嵌入应用B的功能而产生的跨域问题后，应用B的功能能正常使用了。但也产生了另外一个问题：打开应用A的任何页面都会跳转主页，问题原因是：session丢失。




具体分析：　　
　　session是通过在客户端生成一个cookie，所有请求会带上这个cookie。一个cookie的NAME、Domain和Path属性值均相同，则会覆盖，若未设置Domain域，则域为ip（不包括端口），因此应用A的session被应用B的session覆盖了。
　　
　　
　　
　　
　　经测试：tomcat、weblogic、websphere的session默认都是JSESSIONID 为key来识别的，因此在没有特别设置下，同一个域下的多个应用session会互相覆盖。
　　解决办法：
　　设置各个应用使用不同的cookie-name，或者将JSESSIONID的path路径设置为不同。
　　1）WebLogic的Cookie相关配置：weblogic.xml
　　

属性名	默认值	值
cookie-name	JSESSIONID	如未设置，默认为“JSESSIONID”
cookie-path	NULL	如未设置，默认为“/”
cookie-domain	NULL	如未设置，默认为发放cookie的服务器的域

　　


示例代码：  


1.    2.    3.  CookieName  4.  HADFCookie  5.    6.  





延伸阅读：1.  关于WebLogic的Session丢失的问题  http://blog.iyunv.com/DesignLife/article/details/2552186

          2. WebLogic如何设置session超时时间  http://tonyaction.blog.iyunv.com/227462/201900





　　2）websphere的设置（设置不同JSESSIONID的path）
　　应用程序->企业应用程序-> [Application Server] ->
会话管理->1.覆盖会话管理(需打钩).
会话管理->2.启用 cookie(需打钩)->修改'Cookie路径'



　　3）Tomcat的设置（设置不同JSESSIONID的path）
　　修改tomcat/conf/server.xml：
　　
　　1.tomcat5修改方法
　　在启动项中增加org.apache.catalina.SESSION_COOKIE_NAME参数

　　linux
JAVA_OPTS=’-Dorg.apache.catalina.SESSION_COOKIE_NAME=yousessionname‘
　　win
set JAVA_OPTS=”-Dorg.apache.catalina.SESSION_COOKIE_NAME=yousessionname“

　　2.tomcat6和tomcat7修改方法相同
　　在Context容器标签上增加sessionCookieName参数

　　

　　还可以加上sessionCookiePath

...

　　延伸阅读：tomcat修改jsessionid在cookie中的名称 http://blog.shilimin.com/338.htm
　　==================================================
　　http://blog.iyunv.com/e_wsq/article/details/7555667
　　问题：部署3个应用（访问IP相同,域名不同,端口不同），3个应用之间的session 相互影响
　　原因：session是通过在客户端生成一个cookie，所有请求会带上这个cookie，（例如在weblogic中默认这个cookie的名称为JSESSIONID),例如都是发布在weblogic下，则互相访问时，由于未设置cookie-name，默认cookie-name是JSESSIONID，因此客户端中的cookie会互相覆盖，从而导致session混乱
　　一个cookie的NAME、Domain和Path属性值均相同，则会覆盖，若未设置Domain域，则域为ip（不包括端口），因此三个应用的session cookie就会互相覆盖
　　
　　解决办法：设置各个应用使用不同的cookie-name，或者将JSESSIONID的path路径设置为不同
　　1）weblogic的设置（设置不同的cookie-name）：
　　请在WEB-INF\Weblogic.xml添加如下代码
　　      
　　JSESSIONID1  
　　
　　2）websphere的设置（设置不同JSESSIONID的path）
　　应用程序->企业应用程序-> [Application Server] ->
会话管理->1.覆盖会话管理(需打钩).
会话管理->2.启用 cookie(需打钩)->修改'Cookie路径'
　　
　　参考文档：
　　
　　
　　资料一：
　　在将LWAP开发的应用迁移为Oracle ADF来开发的过程中，LWAP和ADF应用都部署在同一个Weblogic服务器的两个Domain下，
　　当在IE中首先访问ADF应用，然后再另外一个标签页中访问LWAP应用，就会发现ADF应用出现问题，就会发现session丢失。
　　问题是由于客户端访问ADF应用时，对应的Weblogic域会保留一个名为JSessionId的Cookie，记录ADF域的信息，JSessionId为
　　Weblogic cookie-name的默认值，而当再次访问LWAP时，客户端Cookie中的JSessionId的值被LWAP的域修改了，此时再次访问
　　之前的ADF应用就会导致Session丢失。
　　网上可以找到关于这个问题的解决方案：
　　1，设置web应用的Cookie名称，让它们拥有不同的JSessionId
　　在LWAP和ADF的weblogic.xml文件添加如下属性
　　

CookieName
HADFCookie


　　2，一个应用使用IP来访问，另外一个应用使用域名来访问
　　一、现象：
　　在WebLogic中，有两个不同域A（端口：9000）和B（端口：8000），应用CA在域A中，应用CB在域B中，进行如下操作：
　　1、先登录应用CA，再登录应用CB，然后，切换回应用CA，发现应用CA的Session丢失；
　　2、应用CA中有指向应用CB的链接，登录应用CA，点击指向应用CB的链接，应用CA的Session丢失；
　　二、原因：
　　因Cookie冲突导致Session丢失。
　　Cookie的覆盖机制：如果一个新的cookie与一个已存在的cookie的NAME、Domain和Path属性值均相同，则旧的cookie会被丢弃。（参考：http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies）
　　WebLogic的Cookie相关配置：
　　

属性名	默认值	值
cookie-name	JSESSIONID	如未设置，默认为“JSESSIONID”
cookie-path	NULL	如未设置，默认为“/”
cookie-domain	NULL	如未设置，默认为发放cookie的服务器的域

　　
　　由于没有在Weblogic.xml配置文件中对cookie的相关属性值进行配置，因此应用CA和应用CB的cookie的Name、Domain和Path属性值均为默认值，即Name为JSESSIONID，Path为“/”，Domain为服务器的IP地址，三个属性值均相同，这就造成了应用CA的cookie与应用CB的cookie会互相覆盖，从而导致相应应用的session丢失。
　　三、解决办法：
　　在Weblogic.xml配置文件中增加Cookie的相应属性值的配置：
　　方法1：设置各应用的cookie的Name属性为不同值
　　方法2：设置各应用的cookie的Path属性为不同值（cookie的Path属性值需与context-root值保持一致，context-root若未在Weblogic.xml中指定则默认为部署的WAR包名或文件夹名，若同一Weblogic服务器不同域中的两应用context-root相同，则此方法不可行）
　　附注：虽然问题是在WebLogic下的不同域部署应用进行互访的情况下发现的，但是，从问题产生的原因来看，在同一个域中的不同应用的互访，如果未做cookie相关属性值的配置，也会出现cookie冲突的问题。
　　
　　
　　资料二：
　　1 关于WebLogic的Session丢失的问题
http://blog.iyunv.com/DesignLife/article/details/2552186
2 tomcat向weblogic移植出现的问题系列 - session丢失问题
(其中一位网友回答不知是什么意思,要加什么文件)
http://netliving.iteye.com/blog/148485
3 java weblogic session 丢失
http://hi.baidu.com/leftstone/blog/item/3b34a4a19d4d0588471064f0.html
4 weblogic两个domain中jsp相互调用session丢失解决方法
http://www.4ucode.com/Study/Topic/1159787
5 关于WebLogic的Session丢失的问题
http://hi.baidu.com/goylsf/blog/item/d2446677d71e070ab051b98d.html
6 weblogic通过代理插件weblogic.servlet.proxy.HttpProxyServlet跨域访问导致session丢失问题的解决
http://ribbonchen.blog.163.com/blog/static/1183165052011074500877/
7 WebLogic如何设置session超时时间
http://tonyaction.blog.iyunv.com/227462/201900
注意网上有很多的Webloigc不是最新的配置
位于WEB-INF/WebLogic.xml配置如下：




Java代码

• 
  
•   
  
•    
  
•         true
  
•    
  
•     /
  
•    
  
•         
  
•         
  
•         JSESSIONID1
  
•    
  
• 　　
  一 WebLogic设置Session超时
  1 web.xml
  设置WEB应用程序描述符web.xml里的元素。这个值以分钟为
  单位，并覆盖weblogic.xml中的TimeoutSecs属性
  
  
  
  
  Java代码
  
  
  • 
    
  •     30
    
  • 
    
  　　
  此例表示Session将在54分钟后过期
  当设置为－2，表示将使用在weblogic.xml中设置的
  TimeoutSecs这个属性值。
  当设置为－1，表示Session将永不过期，而忽略在
  weblogic.xml中设置的TimeoutSecs属性值。
  该属性值可以通过console控制台来设置
  在weblgoic的console中：xxDomain－>Servers->xxServer->Protocols->HTTP 中有一个关于Post Timeout的配置，但这个参数一般使用默认值即可
  一般是通过Services-->JDBC-->Connection Pools-->MyConnection(你所建立的连接池名)－－>Configration-->Connections 里的Inactive Connection Timeout这个参数来设置的，默认的为0，表示连接时间无限长。你可以设一个时间值，连接超过这个时间值，它会把连接强制放回连接池
  
  
  
  
  Java代码
  
  
  
  • 
    
  　　
  是否IdleConnectionTimeout参数
  2 weblogic.xml
  设置WebLogic特有部署描述符weblogic.xml的元素的
  TimeoutSecs属性。这个值以秒为单位
  
  
  
  
  Java代码
  
  
  
  • 
    
  •         
    
  •        7200
    
  • 
    
  　　
  二 防止Webloigic下的iframe的Session失效
  请在Weblogic.xml添加如下代码
  
  
  
  
  Java代码
  
  
  
  • 
    
  •         JSESSIONID1
    
  • 
    
  　　
  原来session在服务器端生成后分配的sessionID在客户端的保存方式是个cookie，它的生命周期在浏览器关闭后就会结束，而这个cookie的名字如果不特别设置，weblogic会以默认的名称“JSESSIONID”来设置这个cookie的名称，我两个应用的的session cookie名字都没有设置，客户端在第一次通过应用A请求代理转发到应用B时，应用B返回的同名session cookie覆盖了客户端原本的应用A的session cookie，所以导致了应用A session的丢失。
  解决方法是，在应用B的weblogic.xml中的session descriptor标记中添加session cookie的名称设置，使其区别于A应用的session cookie名称.其中的cookie-name可以重命名!解决在iframe中进行跨域访问时session丢失的问题
  附件有：weblogic-web-app.xsd
  　　
  　　资料三：
  
  Tomcat改变JSESSIONID Set-Cookie的 Path
  　　Set-Cookie: JSESSIONID=6941712CDVA075E14PF0C8DB15UF78E5; Path=/mywebapp
  如果想将Path=/mywebapp 转为 /
  即：
  Set-Cookie: JSESSIONID=16FB366B425C1EECD229BE1A395FD37C; Path=/
  修改tomcat/conf/server.xml：
  
  
  
  
  Xml代码
  
  
  
  • 
    
  　　
  上面是针对tomcat6的，如果是tomcat7，emptySessionPath该属性无效，
  需要在context.xml加sessionCookiePath：
  ...
  
  
  
• 
  
  

　　===================================================
　　http://hi.baidu.com/avill/item/fe0946da2ed382feca0c3940
　　
　　WebLogic不同域的Cookie冲突问题
　　2009年10月1日小马没有评论
　　一、现象：
　　在WebLogic中，有两个不同域A（端口：9000）和B（端口：8000），应用CA在域A中，应用CB在域B中，进行如下操作：
　　1、先登录应用CA，再登录应用CB，然后，切换回应用CA，发现应用CA的Session丢失；
　　2、应用CA中有指向应用CB的链接，登录应用CA，点击指向应用CB的链接，应用CA的Session丢失；
　　二、原因：
　　因Cookie冲突导致Session丢失。
　　Cookie的覆盖机制：如果一个新的cookie与一个已存在的cookie的NAME、Domain和Path属性值均相同，则旧的cookie会被丢弃。（参考：http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies）
　　WebLogic的Cookie相关配置：
　　属性名
　　默认值值cookie-nameJSESSIONID如未设置，默认为“JSESSIONID”cookie-pathNULL如未设置，默认为“/”cookie-domainNULL如未设置，默认为发放cookie的服务器的域
　　由于没有在Weblogic.xml配置文件中对cookie的相关属性值进行配置，因此应用CA和应用CB的cookie的Name、 Domain和Path属性值均为默认值，即Name为JSESSIONID，Path为“/”，Domain为服务器的IP地址，三个属性值均相同，这就造成了应用CA的cookie与应用CB的cookie会互相覆盖，从而导致相应应用的session丢失。
　　三、解决办法：
　　在Weblogic.xml配置文件中增加Cookie的相应属性值的配置：
　　方法1：设置各应用的cookie的Name属性为不同值
　　方法2：设置各应用的cookie的Path属性为不同值（cookie的Path属性值需与context-root值保持一致，context-root若未在Weblogic.xml中指定则默认为部署的WAR包名或文件夹名，若同一Weblogic服务器不同域中的两应用 context-root相同，则此方法不可行）
　　附注：虽然问题是在WebLogic下的不同域部署应用进行互访的情况下发现的，但是，从问题产生的原因来看，在同一个域中的不同应用的互访，如果未做cookie相关属性值的配置，也会出现cookie冲突的问题。
　　======================================================
　　http://www.myexception.cn/web/902772.html

使用会话和会话持久性

以下部分描述如何设置和使用会话以及会话持久性：

• HTTP 会话概述
  
• 设置会话管理
  
• 配置会话持久性
  
• 用 URL 重写替换 Cookie
  
• Servlet 会话跟踪
  

　　


HTTP 会话概述

通过会话跟踪，您可以跟踪用户在多个自身无状态的 servlet 或 HTML 页面上的进度。会话被定义为特定时间段内来自同一个客户端的一系列相关的浏览器请求。会话跟踪将一系列浏览器请求联结起来（可以将这些请求当作页面来考虑），这些请求整体上可能具有一定的含义，例如购物车应用程序。
　　


设置会话管理

默认情况下，WebLogic Server 设置为可以处理会话跟踪。无需设置以下任何属性即可使用会话跟踪。但是，配置 WebLogic Server 管理会话的方式是调整应用程序以获得最佳性能的关键部分。设置会话管理时，您需确定如下因素：

• 预期访问 servlet 的用户的数量
  
• 每个会话的持续时间
  
• 每个用户的预期数据存储量
  
• 向 WebLogic Server 实例分配的堆大小
  

您还可以永久存储来自 HTTP 会话的数据。请参阅配置会话持久性 。

HTTP 会话属性

通过在 WebLogic 特定的部署描述符 weblogic.xml 中定义各种属性，您可以配置 WebLogic Server 会话跟踪。有关会话特性的完整列表，请参阅 session-descriptor 。
在以前的 WebLogic Server 版本中，引入了对 SessionID 格式的一个更改，以致某些负载平衡器丧失了保持会话粘滞性的能力。服务器启动标志 -Dweblogic.servlet.useExtendedSessionFormat=true 保留了负载均衡应用程序保持会话粘滞性所需要的信息。如果激活了 URL 重写功能，且启动标志设置为真，则扩展会话 ID 格式将属于 URL 的一部分。

会话超时

您可以指定 HTTP 会话过期的时间间隔。会话过期时，将放弃会话中存储的所有数据。可以在 web.xml 或 weblogic.xml 中设置时间间隔：

• 在 WebLogic 特定的部署描述符 weblogic.xml 中的 session-descriptor 元素中设置 timeout-secs 参数值。该值以秒为单位进行设置。有关详细信息，请参阅 session-descriptor 。
  
• 在 J2EE 标准 Web 应用程序部署描述符 web.xml 中设置 session-timeout 元素。
  

配置 WebLogic Server 会话 Cookie

客户端浏览器支持 cookie 时，WebLogic Server 使用 cookie 进行会话管理。
默认情况下，WebLogic Server 用于跟踪会话的 cookie 设置为暂态，其生存期不会超过会话期间。用户退出浏览器时，cookie 丢失，会话结束。此行为主要用于会话，建议您以此方式使用会话。
您可以在 WebLogic 特定部署描述符 weblogic.xml 中配置 cookie 的 session-tracking 参数。会话及 cookie 相关参数的完整列表位于 session-descriptor 中。

配置生存期超过会话期间的应用程序 Cookie

要获得生存期更长的客户端用户数据，您可以编写自己的应用程序，通过 HTTP servlet API 在浏览器上创建和设置自己的 cookie。应用程序不应试图使用与 HTTP 会话关联的 cookie。您的应用程序可能会使用 cookie 以使用户从特定计算机自动登录，这样，您需要设置新的 cookie 以持续更长时间。请记住，只能从此特定客户端计算机发送 cookie。如果用户必须从多个位置进行访问，您的应用程序应该在服务器上存储数据。
您不能直接将浏览器 cookie 的期限与会话时间长度关联起来。否则，如果 cookie 在其关联会话之前过期，则会话会变得孤立。而如果会话在其关联 cookie 之前过期，则 servlet 无法找到该会话。这种情况下，当调用request.getSession(true) 方法时，将自动分配一个新会话。
可以使用 weblogic.xml 部署描述符的会话描述符中的 cookie-max-age-secs 元素设置 cookie 的最大生命周期。请参阅 cookie-max-age-secs 。

退出和结束会话

用户身份验证信息既存储于用户会话数据中，也存储于 Web 应用程序所定位的服务器或虚拟主机的上下文中。通常用于使用户退出的 session.invalidate() 方法仅使用户的当前会话失效，用户身份验证信息仍有效，且存储于服务器或虚拟主机的上下文中。而如果服务器或虚拟主机仅承载一个 Web 应用程序，则 session.invalidate() 方法实际上会使用户退出。
针对多个 Web 应用程序使用身份验证时，有多种 Java 方法和策略可以使用。有关详细信息，请参阅退出和结束会话 。

使 Web 应用程序共享同一个会话

默认情况下，Web 应用程序不共享同一个会话。如果您希望 Web 应用程序共享同一个会话，您可以在 weblogic-application.xml 部署描述符中配置应用程序级别上的会话描述符。要使 Web 应用程序共享同一个会话，请将weblogic-application.xml 部署描述符中会话描述符中的 sharing-enabled 特性设置为 true 。请参阅 session-descriptor 中的“sharing-enabled”。
应用程序级别上指定的会话描述符配置将替代在 Web 应用程序级别上为应用程序中所有 Web 应用程序指定的任何会话部署描述符配置。如果您在 Web 应用程序级别上将 sharing-enabled 特性设置为真，则将忽略该设置。
如果您在 weblogic-application.xml 部署描述符中指定会话描述符，并将 sharing-enabled 特性设置为 true ，则应用程序中的所有 Web 应用程序将自动使用同一个会话实例启动，如以下示例所示：
　　




　　




...

memory
true
...

...

　　


配置会话持久性

使用会话持久性永久存储 HTTP 会话对象中的数据，以便支持 WebLogic Server 群集之间的故障转移和负载平衡，应用程序存储 HTTP 会话对象中的数据时，数据必须是可序列化的。
会话持久性有五种不同的实现方法：

• 内存（单个服务器，非复制）
  
• 文件系统持久性
  
• JDBC 持久性
  
• 基于 Cookie 的会话持久性
  
• 内存中复制（跨群集）
  

此处仅讨论前四项；内存中复制将在使用 WebLogic Server 群集 中的 HTTP 会话状态复制 中讨论。
基于文件、JDBC 和 cookie 的会话持久性与内存（单服务器，非填充）会话持久性具有某些共同的属性。每个持久性方法具有其自己的一组可配置参数，如以下部分所讨论。这些参数是 weblogic.xml 部署描述符文件中 session-descriptor 元素的子元素。

不同类型的会话持久性的共有特性

此部分描述基于文件的持久性和基于 JDBC 的持久性共用的参数。通过在 weblogic.xml 部署描述符文件中的 session-descriptor 元素中定义下列参数，您可以配置内存中保留的会话数量。以下参数仅适用于您使用会话持久性时：

cache-size


限制内存中一次可存在的活动缓存会话数目。如果您期望使用大量的同时处于活动状态的会话，则您会希望这些会话不要耗尽服务器的内存，否则会因反复与虚拟内 存之间进行交换而导致性能问题。当缓存满时，最近不常使用的会话将存储于永久性存储中，需要时会自动重新调用它们。如果不使用持久性，将忽略此属性，且对 主内存中允许的会话数量没有任何软限制。默认情况下，缓存中的会话数量是 1028。要关闭缓存，请将此值设置为 0。请参阅 cache-size 。

注意：	基于 JDBC 和基于文件的会话使用 cache-size 的目的仅仅是维护内存中出现的缓存。它不适用于其他持久性类型。

invalidation-interval-secs


设置 WebLogic Server 在执行超时会话和无效会话的清理检查与删除旧会话并释放内存之间需要等待的时间（秒）。使用此元素调整 WebLogic Server 以在高流量站点上获得最佳性能。请参阅 invalidation-interval-secs 。

最小值是每秒 1 次(1)。最大值是每周一次（604,800 秒）。如果没有设置，则特性默认为 60 秒。
使用基于内存的单服务器非复制持久性存储

使用基于内存的存储时，所有会话信息都存储在内存中，当您停止并重新启动 WebLogic Server 时，这些信息都会丢失。要使用基于内存的单服务器非复制持久性存储，请将 weblogic.xml 部署描述符文件中的 session-descriptor 元素中 persistent-store-type 参数设置为 memory。请参阅 persistent-store-type 。
　　

注意：	如果运行 WebLogic Server 时没有分配足够的堆大小，服务器将由于高额负载而导致内存不足。

使用基于文件的持久性存储

要为会话配置基于文件的持久性存储，请执行下列操作：

• 在部署描述符文件 weblogic.xml 中，将 weblogic.xml 部署描述符文件中 session-descriptor 元素中的persistent-store-type 参数设置为 file 。请参阅 persistent-store-type 。
  
• 设置 WebLogic Server 存储会话的目录。请参阅 persistent-store-dir 。
  

注意：	必须自行创建此目录，并确保已为该目录分配适当的访问权限。

使用数据库进行持久性 存储（JDBC 持久性）

JDBC 持久性通过使用专为此目的而提供的 Schema 将会话数据存储在数据库表中。可以使用您有 JDBC 驱动程序的任何数据库。通过使用连接缓冲池配置数据库访问。
由于 WebLogic Server 在使用 JDBC 会话持久性时会使用系统时间确定会话生命周期，所以您必须确保其上服务器是在同一个群集中运行的所有计算机上的系统时钟。

配置基于 JDBC 的持久性存储

要为会话配置基于 JDBC 的持久性存储，请执行下列步骤：

• 将 weblogic.xml 部署描述符文件中 session-descriptor 元素中的 persistent-store-type 参数设置为 jdbc 。请参阅 persistent-store-type 。
  
• 使用 weblogic.xml 部署描述符文件中 session-descriptor 元素中的 persistent-store-pool 参数设置要用于持久性存储的 JDBC 连接缓冲池。使用 WebLogic Server 管理控制台中定义的连接缓冲池的名称。请参阅 persistent-store-pool 。
  
• 为基于 JDBC 的持久性设置一个名为 wl_servlet_sessions 的数据库表。连接数据库的连接缓冲池需要具有该表的读/写访问权。
  

注意：	如果数据库没有自动创建索引，请在 wl_id 和 wl_context_path 上创建。某些数据库会自动为主关键字创建索引。

按如下说明设置列名称和数据类型。


表 8-1 创建 wl_servlet_sessions

列名

数据类型

wl_id	变量宽度字母数字列，最多 100 位字符；例如 Oracle VARCHAR2(100) . 主关键字必须按如下设置： wl_id + wl_context_path.
wl_context_path	变量宽度字母数字列，最多 100 位字符；例如 Oracle VARCHAR2(100) 。此列用作主关键字的一部分。（请参阅 wl_id 列描述。）
wl_is_new	单字符列，例如 Oracle CHAR(1)
wl_create_time	数值列，20 位，例如 Oracle NUMBER(20)
wl_is_valid	单字符列，例如 Oracle CHAR(1)
wl_session_values	大型二进制列；例如 Oracle LONG RAW
wl_access_time	数值列，20 位；例如 NUMBER(20)
wl_max_inactive_interval	整数列；例如 Oracle Integer 。如果两个客户端请求之间的时间超过此秒数，则会话将失效。负时间值表明会话永不超时。

如果您使用的是 Oracle DBMS，请使用下面的 SQL 语句创建 wl_servlet_sessions 表。请修改该 SQL 语句以用于您的 DBMS。


清单 8-1使用 Oracle DBMS 创建 wl_servlet_sessions 表　　



create table wl_servlet_sessions
( wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL,
wl_is_new CHAR(1),
wl_create_time NUMBER(20),
wl_is_valid CHAR(1),
wl_session_values LONG RAW,
wl_access_time NUMBER(20),
wl_max_inactive_interval INTEGER,
PRIMARY KEY (wl_id, wl_context_path) );
　　

注意：	您可以使用 jdbc-connection-timeout-secs 参数配置 JDBC 会话持久性等待连接缓冲池中的 JDBC 连接的最大持续时间，超过该时间将无法加载会话数据。有关详细信息，请参阅 jdbc-connection-timeout-secs 。

如果您使用的是 SqlServer2000，请使用下面的 SQL 语句创建 wl_servlet_sessions 表。请修改该 SQL 语句以用于您的 DBMS。


清单 8-2 使用 SqlServer 2000 创建 wl_servlet_sessions 表　　



create table wl_servlet_sessions
( wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL,
wl_is_new VARCHAR(1),
wl_create_time DECIMAL,
wl_is_valid VARCHAR(1),
wl_session_values IMAGE,
wl_access_time DECIMAL,
wl_max_inactive_interval INTEGER,
PRIMARY KEY (wl_id, wl_context_path) );
如果您使用的是 Pointbase，Pointbase 会转换该 SQL。例如，Pointbase 会按照如下方式转换清单 8-1 中提供的 SQL。


清单 8-3 使用 Pointbase SQL 转换创建 wl_servlet_sessions 表　　



SQL> describe wl_servlet_sessions;
　　



WL_SERVLET_SESSIONS
　　



WL_ID VARCHAR(100) NULLABLE: NO
　　



WL_CONTEXT_PATH VARCHAR(100) NULLABLE: NO
　　



WL_IS_NEW CHARACTER(1) NULLABLE: YES
　　



WL_CREATE_TIME DECIMAL(20) NULLABLE: YES
　　



WL_IS_VALID CHARACTER(1) NULLABLE: YES
　　



WL_SESSION_VALUES BLOB(65535) NULLABLE: YES
　　



WL_ACCESS_TIME DECIMAL(20) NULLABLE: YES
　　



WL_MAX_INACTIVE_INTERVAL INTEGER(10) NULLABLE: YES
　　



Primary Key: WL_CONTEXT_PATH
　　



Primary Key: WL_ID
如果您使用的是 DB2，请使用下面的 SQL 语句创建 wl_servlet_sessions 表。请修改该 SQL 语句以用于您的 DBMS。


清单 8-4 使用 DB2 创建 wl_servlet_sessions 表　　



CREATE TABLE WL_SERVLET_SESSIONS
(
WL_ID VARCHAR(100) not null,
WL_CONTEXT_PATH VARCHAR(100) not null,
WL_IS_NEW SMALLINT,
WL_CREATE_TIME DECIMAL(16),
WL_IS_VALID SMALLINT,
wl_session_values BLOB(10M) NOT LOGGED,
WL_ACCESS_TIME DECIMAL(16),
WL_MAX_INACTIVE_INTERVAL INTEGER,
PRIMARY KEY (WL_ID,WL_CONTEXT_PATH)
　　



);
如果您使用的是 Sybase，请使用下面的 SQL 语句创建 wl_servlet_sessions 表。请修改该 SQL 语句以用于您的 DBMS。


清单 8-5 使用 Sybase 创建 wl_servlet_sessions 表　　



create table WL_SERVLET_SESSIONS (
WL_ID                         varchar(100)                   not null  ,
WL_CONTEXT_PATH               varchar(100)                   not null  ,
WL_IS_NEW                     smallint                           null  ,
WL_CREATE_TIME                decimal(16,0)                      null  ,
WL_IS_VALID                   smallint                           null  ,
WL_SESSION_VALUES             image                              null  ,
WL_ACCESS_TIME                decimal(16,0)                      null  ,
WL_MAX_INACTIVE_INTERVAL      int                                null  ,
)
go
alter table WL_SERVLET_SESSIONS
add PRIMARY KEY CLUSTERED (WL_ID, WL_CONTEXT_PATH)
go
JDBC 会话持久性的缓存与数据库更新

如果请求是只读的，WebLogic Server 不会向磁盘中写入 HTTP 会话状态，这表明该请求不修改 HTTP 会话。如果访问该会话，则仅更新数据库中的 wl_access_time 列。
对于非只读请求，每次 HTTP 请求后，Web 应用程序容器都会在数据库中更新会话状态的变化。因此，群集中的任意服务器均可处理一旦发生故障转移时的请求，并从数据库中检索最新会话状态。
为防止多个数据库查询，WebLogic Server 将缓存最近使用的会话。每次请求时，并不从数据库中刷新最近使用的会话。缓存中会话的数量由 WebLogic Server 特定的部署描述符 weblogic.xml 中的 cache-size 参数控制。请参阅 cache-size 。

使用基于 Cookie 的会话持久性

基于 Cookie 的会话持久性提供了会话持久性的无状态解决方案，方法是将所有会话数据存储在用户浏览器的 cookie 中。不需要在会话中存储大量数据时，基于 Cookie 的会话持久性最适用。由于不需要群集故障转移逻辑，所以基于 Cookie 的会话持久性能够简化 WebLogic Server 安装的管理。由于会话存储于浏览器中，而不存储于服务器上，所以启动和停止 WebLogic Server 时不会丢失会话。
基于 cookie 的会话持久性具有某些限制：

• 只能存储会话中的字符串特性。如果您存储会话中的任何其他类型的对象，则会引发 IllegalArgument 异常。
  
• 不能刷新 HTTP 响应（因为必须先将 cookie 写入头数据中，然后才可以提交响应 ）。
  
• 如果响应内容的长度超出缓冲大小，则自动刷新响应，不更新 cookie 中的会话数据。（缓冲大小默认为 8192 字节。）您可以使用 javax.servlet.ServletResponse.setBufferSize() 方法更改缓冲区大小。
  
• 只能使用基本（基于浏览器）身份验证。
  
• 会话数据以明文方式发送至浏览器。
  
• 必须对用户浏览器进行配置以接受 cookie。
  
• 使用基于 cookie 的会话持久性时，字符串内不能使用逗号，否则会引发异常。
  

要设置基于 cookie 的会话持久性，请执行下列步骤：

• 将 weblogic.xml 部署描述符文件中 session-descriptor 元素中的 persistent-store-type 参数设置为 cookie。请参阅 persistent-store-type 。
  
• 或者，使用 persistent-store-cookie-name 元素为 cookie 设置一个名称。默认值为 WLCOOKIE 。请参阅 persistent-store-cookie-name 。
  

　　


用 URL 重写 替换 Cookie

在某些情况下，浏览器或无线设备可能不接受 cookie，因此无法使用 cookie 进行会话跟踪。对于这种情况，URL 重写是一个解决方案，当 WebLogic Server 检测到浏览器不接受 cookie 时，会自动替换为 URL 重写。URL 重写包括将会话 ID 编码到 servlet 传回浏览器的那些网页的超链接中。当用户随后单击这些链接时，WebLogic Server 将从 URL 地址中提取 ID，并在 servlet 调用 getSession() 方法时查找相应的 HttpSession 。
在 WebLogic 特定的部署描述符 weblogic.xml 中的 session-descriptor 元素下，设置 url-rewriting-enabled 参数，从而启用 WebLogic Server 中的 URL 重写。此特性的默认值是 true 。请参阅 url-rewriting-enabled 。

URL 重写的编码准则

下面是支持 URL 重写的一般准则。

• 避免直接向输出流中写入 URL，如下显示：
  

out.println("catalog");
而要使用 HttpServletResponse.encodeURL() 方法，例如：




out.println("