session过期时间设置说明
session 过期时间设置说明一. 系统session 配置说明针对承保(prpall)、双核(undwrt)系统中，有两个配置文件可以设置session 的过期时间 分别是web.xml 和we
session 过期时间设置说明
一. 系统session 配置说明
针对承保(prpall)、双核(undwrt)系统中，有两个配置文件可以设置session 的过期时间 分别是web.xml 和weblogic.xml
Web.xml 中配置
时间单位是一分钟，并且只能是整数，如果是零或负数，那么会话就永远不会超时。 此例表示Session 将在60分钟后过期
weblogic.xml 中设置的TimeoutSecs 属性值。
Weblogic.xml 中配置
时间单位是一秒钟，表示1800秒后失效。
1. 如果两个配置文件中都有配置，且Weblogic.xml 中配置的秒数必须可以被60整除，(如60，120等) 。则按照时间最小的那个为准。
2. 如果两个配置文件中都有配置, 且Weblogic.xml 中配置的秒数必须不可以被60整除（如，45，90等）。则以web.xml 设置的时间为准。
3. 如果web.xml 文件中没有设置，且Weblogic.xml 中有配置。则按照Weblogic.xml 的设置为准。
4. 为保证session 的唯一性，在weblogic 环境下，建议只在weblogic.xml 中设置。防止出现冲突。
,二. 疑问
1. web.xml,weblogic.xml 同时配置时，为什么会是以时间小的为准？ 暂时无解。
2. 对应的weblogic.xml 必须配置为分钟的整数倍？
如web=2m weblogic=90s，最终为以web 为准。
web=3m weblogic=120s 以 weblogic为准
暂时无解。
3. 关于“WEB-INF/config/appconfig/SysConstConfig.xml” 中的session 时效时间。 从目前情况看， SysConstConfig.xml 这个应该没有使用；那么就是 web.xml 与weblogic.xml 这两个的配置用谁的问题了。
按网上说法，对应的优先级应该是：自定义xml 配置的session>web.xml>weblogic.xml；个人理解为：自定义的配置最高的原因是因为，我们程序实现判断session 时去读取了这个时间；对于web.xml>weblogic.xml，从上述的测试过程中发现并不是如此。
三. 配置session 方式
WebLogic 如何设置session 超时时间
1 web.xml
设置WEB 应用程序描述符web.xml 里的
此例表示Session 将在54分钟后过期
当
TimeoutSecs 这个属性值。
当
weblogic.xml 中设置的TimeoutSecs 属性值。
该属性值可以通过console 控制台来设置
2 weblogic.xml
设置WebLogic 特有部署描述符weblogic.xml 的
默认值是3600秒
3,jsp 中控制
session.setmaxinactiveinterval(7200);
session 是默认对象, 可以直接引用, 单位秒s
4,servlet 中控制
session.setmaxinactiveinterval(7200);
单位秒s
在weblgoic 的console 中：xxDomain －>Servers->xxServer->Protocols->HTTP 中有一个关于Post Timeout的配置，但这个参数一般使用默认值即可
一般是通过Services-->JDBC-->Connection Pools-->MyConnection(你所建立的连接池名) －－>Configration-->Connections 里的Inactive Connection Timeout这个参数来设置的，默认的为0，表示连接时间无限长。你可以设一个时间值，连接超过这个时间值，它会把连接强制放回连接池
CompleteMessageTimeout="480" IdleConnectionTimeout="600" ListenAddress="" ListenPort="7001" Name="myserver" NativeIOEnabled="true" ReliableDeliveryPolicy="RMDefaultPolicy" ServerVersion="8.1.4.0"> 是否IdleConnectionTimeout 参数 看连接池中高级选项内的Inactive Connection Timeout和Connection Reserve Timeout时多少， 把这两项设大些试试 如果在两个文件中同时设置了超时时间，则会以web.xml 中为准。 所以在weblogic 环境中，最好将web.xml 中关于超时的设置删掉，保持唯一性。 如果使用WEBLOGIC 作为应用服务器，设置SESSION 超时时间会选择在WEBLOGIC 的控制台设定。实际上，WEBLOGIC 是将超时设定保存在WEB-INF 下的weblogic.xml 中，格式如下： param-value 中的数值就是超时时间，单位为秒。在设置完这个参数后，会发现超时时间并一定起效。这是为什么呢？ 原来在WEB-INF 下还有一个配置文件web.xml ，里面同样会有一段设置session ，格式如下： session-timeout 中的值也是超时时间，单位为分钟。 如果在两个文件中同时设置了超时时间，则会以web.xml 中为准。 所以在weblogic 环境中，最好将web.xml 中关于超时的设置删掉，保持唯一性。 这也是发现了问题后，多次实验后发现的。 以下问题： ueue: ‘billproxyqueue ’ has been busy for “727″ seconds working on the request “Http Request: /bill/y nQueryPublic.go ”, which is more than the configured time (StuckThreadMaxTime) of “600″ seconds.> 一看明显是连接超时, 导致的错误. 程序问题, 是不是程序中没有关闭连接 如果程序没问题, 则是weblogic 的StuckThreadMaxTime 设置过小而引起的, 一般weblogic server 的StuckThreadMaxTime 默认参数是600s, 即10分钟, 如果并发量过大, 而导致等待处理过多, 导致系统不停的增加线程，造成线程阻塞，你可以把该参数设置大点这个是稍微调大StuckThreadMaxTime 的参数即可. 看线程数设置, 可适当增加线程数，这个在WLS 控制台中可以调整 四. 关于session 通过 在weblgoic 的console 中配置的补 充： 在weblogic10R3 中配置方法： 登录console 之后，部署>选择对应的应用（如 undwrt）>配置>改完后保存，会另存为其他的xml 文件，如下图流程。 五. s ession 与cookie 的详细说明 具体来说cookie 机制采用的是在客户端保持状态的方案，而session 机制采用的是在服务器端保持状态的方案 同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session 机制可能需要借助于cookie 机制来达到保存标识的目的，但实际上它还有其他选择。 cookie 的内容主要包括：名字，值，过期时间，路径和域。 其中域可以指定某一个域比如.google.com ，相当于总店招牌，比如宝洁公司，也可以指定一个域下的具体某台机器比如www.google.com 或者froogle.google.com ，可以用飘柔来做比。 路径就是跟在域名后面的URL 路径，比如/或者/foo等等，可以用某飘柔专柜做比。 路径与域合在一起就构成了cookie 的作用范围。 如果不设置过期时间，则表示这个cookie 的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie 就消失了。这种生命期为浏览器会话期的 cookie被称为会话cookie 。会话cookie 一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。如果设置了过期时间，浏览器就会把cookie 保存到硬盘上，关闭后再次打开浏览器，这些cookie 仍然有效直到超过设定的过期时间。 存储在硬盘上的cookie 可以在不同的浏览器进程间共享，比如两个IE 窗口。而对于保存在内存里的cookie ，不同的浏览器有不同的处理方式。对于IE ，在一个打开的窗口上按Ctrl-N （或者从文件菜单）打开的窗口可以与原窗口共享，而使用其他方式新开的IE 进程则不能共享已经打开的窗口的内存cookie ；对于Mozilla Firefox0.8，所有的进程和标签页都可以共享同样的cookie 。一般来说是用javascript 的window.open 打开的窗口会与原窗口共享内存cookie 。浏览器对于会话cookie 的这种只认cookie 不认人的处理方式经常给采用session 机制的web 应用程序开发者造成很大的困扰。 [经典的语录] 下面就是一个goolge 设置cookie 的响应头的例子 HTTP/1.1 302 Found Location: http://www.google.com/intl/zh-CN/ Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com Content-Type: text/html 到时候我们的域就要设置为domain=.*****.cn path=/ session 机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。 四、理解session 机制 session 机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。 当程序需要为某个客户端的请求创建一个session 的时候，服务器首先检查这个客户端的请求里是否已包含了一个session 标识 - 称为session id，如果已包含一个session id则说明以前已经为此客户端创建过session ，服务器就按照session id把这个session 检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session 并且生成一个与此session 相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。 保存这个session id 的方式可以采用cookie ，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie 的名字都是类似于 SEEESIONID，而。比如weblogic 对于web 应用程序生成的 cookie， J SESSION ID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是J SESSION ID 。 由于cookie 可以被人为的禁止，必须有其他机制以便在cookie 被禁止时仍然能够把session id 传递回服务器。经常被使用的一种技术叫做URL 重写，就是把session id 直接附加在URL 路径的后面，附加方式也有两种，一种是作为URL 路径的附加信息，表现形式为http://..... /xxx;jsession id=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764 另一种是作为查询字符串附加在URL 后面，表现形式为 这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。 为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。 另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单
在被传递给客户端之前将被改写成
这种技术现在已较少应用，笔者接触过的很古老的iPlanet6(SunONE应用服务器的前身) 就使用了这种技术。
实际上这种技术可以简单的用对action 应用URL 重写来代替。
,在谈论session 机制的时候，常常听到这样一种误解“只要关闭浏览器，session 就消失了”。其实可以想象一下会员卡的例子，除非顾客主动对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对session 来说也是一样的，除非程序通知服务器删除一个session ，否则服务器会一直保留，程序一般都是在用户做log off 的时候发个指令去删除session 。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分session 机制都使用会话cookie 来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session 。如果服务器设置的cookie 被保存到硬盘上，或者使用某种手段改写浏览器发出的 HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session 。
恰恰是由于关闭浏览器不会导致session 被删除，迫使服务器为seesion 设置了一个失效时间，当距离客户端上一次使用session 的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session 删除以节省存储空间。
[写得太精彩了。感受太深了！]
1、session 在何时被创建
一个常见的误解是以为session 在有客户端访问时就被创建，然而事实是直到某server 端程序调用 HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP 没有显示的使用 <@page session="false"> 关闭session ，则JSP 文件在编译成Servlet 时将会自动加上这样一条语句HttpSession session =
HttpServletRequest.getSession(true);这也是JSP 中隐含的session 对象的来历。
由于session 会消耗内存资源，因此，如果不打算使用session ，应该在所有的JSP 中关闭它。
2、session 何时被删除
综合前面的讨论，session 在下列情况下被删除a. 程序调用HttpSession.invalidate();或b. 距离上一次收到客户端发送的session id时间间隔超过了session 的超时设置; 或c. 服务器进程被停止（非持久session ）
3、如何做到在浏览器关闭时删除session
严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascript 代码window.oncolose 来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session 。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。
7、开两个浏览器窗口访问应用程序会使用同一个session 还是不同的session
参见第三小节对cookie 的讨论，对session 来说是只认id 不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie 存储方式都会对这个问题的答案有影响。
8、如何防止用户打开两个浏览器窗口操作导致的session 混乱
这个问题与防止表单多次提交是类似的，可以通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id 返回给客户端，同时保存在session 里，客户端提交表单时必须把
,这个id 也返回服务器，程序首先比较返回的id 与保存在 session里的值是否一致，如果不一致则说明本次操作已经被提交过了。［对不起你已经投过票了！可以这样来进行控制的哦］
八、总结
session 机制本身并不复杂，然而其实现和配置上的灵活性却使得具体情况复杂多变。这也要求我们不能把仅仅某一次的经验或者某一个浏览器，服务器的经验当作普遍适用的经验，而是始终需要具体情况具体分析。
为什么登陆后, 只要不关闭浏览器,session 就能一直存在? 当然session 的数据是保存在服务器上的, 但服务器是怎么识别这些数据都是谁的呢? 答案是sessionid, 每一个浏览者都唯一的sessionid, 这就很好的区分了不同浏览者的不同session 了.sessionid 是怎么产生的? 应该是第一次访问服务器的时候随即生成的. 假如是111, 然后他的登陆信息是true, 服务器就知道sessionid 为111已经登陆了, 这些信息都存在了服务器上了. 但当浏览者继续操作的时候, 也就是打开该系统的另一个页面的时候sessionid 怎么办? 如何传递? 打开另一个页面的时候其实相当于重新访问系统, 如果没有特殊的处理机制, 系统会再次重新分配一个
sessionid 的, 这样的话就失去意义了~!所以sessionid 在第一次访问后应该存在了客户端. 能寸哪呢? 当然, 只能寸在cookie 中了, 这就是为什么关闭cookie,session 就失去作用了
十三、保存session id的几种方式
A ．保存session id的方式可以采用cookie ，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
B ．由于cookie 可以被人为的禁止，必须有其它的机制以便在cookie 被禁止时仍然能够把session id传递回服务器，经常采用的一种技术叫做URL 重写，就是把session id附加在URL 路径的后面，附加的方式也有两种，一种是作为URL 路径的附加信息，另一种是作为查询字符串附加在URL 后面。网络在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。
C ．另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。
二十五、session cookie和session 对象的生命周期是一样的吗
当用户关闭了浏览器虽然session cookie已经消失，但session 对象仍然保存在服务器端
二十六、是否只要关闭浏览器，session 就消失了
,程序一般都是在用户做log off 的时候发个指令去删除session ，然而浏览器从来不会主动在关闭之前通知服务器它将要被关闭，因此服务器根本不会有机会知道浏览器已经关闭。服务器会一直保留这个会话对象直到它处于非活动状态超过设定的间隔为止。
之所以会有这种错误的认识，是因为大部分session 机制都使用会话cookie 来保存session id ，而关闭浏览器后这个session id就消失了，再次连接到服务器时也就无法找到原来的session 。
如果服务器设置的cookie 被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP 请求报头，把原来的session id 发送到服务器，则再次打开浏览器仍然能够找到原来的session 。 恰恰是由于关闭浏览器不会导致session 被删除，迫使服务器为session 设置了一个失效时间，当距离客户上一次使用session 的时间超过了这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session 删除以节省存储空间。
由此我们可以得出如下结论：
关闭浏览器，只会是浏览器端内存里的session cookie消失，但不会使保存在服务器端的session 对象消失，同样也不会使已经保存到硬盘上的持久化cookie 消失。
二十七、打开两个浏览器窗口访问应用程序会使用同一个session 还是不同的session
通常session cookie是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的session id，这样我们信息共享的目的就达不到了。
此时我们可以先把session id 保存在persistent cookie 中(通过设置session 的最大有效时间) ，然后在新窗口中读出来，就可以得到上一个窗口的session id 了，这样通过session cookie 和persistent cookie的结合我们就可以实现了跨窗口的会话跟踪。
2.cookies 的属性有：Domain(域) ：哪个站点发的哪个站点拿走
Expires:是否过期
Haskeys:是否包含关键
path:存放的路径
secure:是否安全
注：－－－cookies 的设置在 sever端设置，路径与域一起构成cookie 的作用范围
? 这个是什么意思的啊？为什么会是在服务器端进行设置的呢？
－－－若不设置过期时间，则表示这个cookie 的生命期为浏览器会话期间，关闭浏览器窗口，cookie 就消失。这种生命期为浏览器会话期的cookie 被称为会话cookie 。会话cookie 一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie 保存到硬盘上，关闭后再次打开浏览器，这些cookie 仍然有效