]]>
׃session?x)消耗内存资源，因此Q如果不打算使用sessionQ应该在所有的JSP中关闭它?br />
2、session何时被删?br />l合前面的讨论，session在下列情况下被删除a.E序调用HttpSession.invalidate();或b.距离上一ơ收到客L(fng)发送的session (tng)id旉间隔过?jin)session的超时设|?或c.服务器进E被停止Q非持久sessionQ?br />
3、如何做到在览器关闭时删除session
严格的讲Q做不到q一炏V可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进E这些非常规手段仍然无能为力?br />
4、有个HttpSessionListener是怎么回事
你可以创L(fng)listenerȝ控session的创建和销毁事Ӟ使得在发生这L(fng)事g时你可以做一些相应的工作。注意是session的创建和销毁动作触发listenerQ而不是相反。类似的与HttpSession有关的listenerq有 (tng)HttpSessionBindingListenerQHttpSessionActivationListener和?tng)HttpSessionAttributeListener?br />
5、存攑֜session中的对象必须是可序列化的?br />不是必需的。要求对象可序列化只是ؓ(f)?jin)session能够在集中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内存。在 (tng)Weblogic (tng)Server的session中放|一个不可序列化的对象在控制C?x)收C个警告。我所用过的某个iPlanet版本如果 (tng)session中有不可序列化的对象Q在session销毁时?x)有一个ExceptionQ很奇怪?br />
6、如何才能正的应付客户端禁止cookie的可能?br />Ҏ(gu)有的URL使用URL重写Q包括超链接Qform的actionQ和重定向的URLQ具体做法参见[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770
7、开两个览器窗口访问应用程序会(x)使用同一个sessionq是不同的session
参见W三节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器Q不同的H口打开方式以及(qing)不同的cookie存储方式都会(x)对这个问题的{案有媄(jing)响?br />
8、如何防止用h开两个览器窗口操作导致的session混ؕ
q个问题?sh)防止表单多ơ提交是cM的，可以通过讄客户端的令牌来解冟뀂就是在服务器每ơ生成一个不同的idq回l客L(fng)Q同时保存在session里，客户端提交表单时必须把这个id也返回服务器Q程序首先比较返回的id与保存在session里的值是否一_(d)如果不一致则说明本次操作已经被提交过?jin)。可以参看《J2EE核心(j)模式》关于表C层模式的部分。需要注意的是对于用javascript (tng)window.open打开的窗口，一般不讄q个idQ或者用单独的idQ以防主H口无法操作Q徏议不要再window.open打开的窗口里做修Ҏ(gu)作，q样可以不用设|?br />
9、ؓ(f)什么在Weblogic (tng)Server中改变session的值后要重新调用一ơsession.setValue
做这个动作主要是Z(jin)在集环境中提示Weblogic (tng)Server (tng)session中的值发生了(jin)改变Q需要向其他服务器进E复制新的session倹{?br />
10、ؓ(f)什么session不见?br />排除session正常失效的因素之外，服务器本w的可能性应该是微乎其微的，虽然W者在iPlanet6SP1加若q补丁的Solaris版本上倒也遇到q；览器插件的可能性次之，W者也遇到q?721插g造成的问题；理论上防火墙或者代理服务器在cookie处理上也有可能会(x)出现问题?br />出现q一问题的大部分原因都是E序的错误，最常见的就是在一个应用程序中去访问另外一个应用程序。我们在下一节讨个问题?br />
七、跨应用E序的session׃n
常常有这L(fng)情况Q一个大目被分割成若干项目开发，Z(jin)能够互不q扰Q要求每个小目作ؓ(f)一个单独的web应用E序开发，可是C(jin)最后突然发现某几个项目之间需要共享一些信息，或者想使用session来实现SSO(single (tng)sign (tng)on)Q在session中保存login的用户信息，最自然的要求是应用E序间能够访问彼此的session?br />
然而按照Servlet规范Qsession的作用范围应该仅仅限于当前应用程序下Q不同的应用E序之间是不能够互相讉KҎ(gu)的session的。各个应用服务器从实际效果上都遵守了(jin)q一规范Q但是实现的l节却可能各有不同，因此解决跨应用程序session׃n的方法也各不相同?br />
首先来看一下Tomcat是如何实现web应用E序之间session的隔ȝQ从 (tng)Tomcat讄的cookie路径来看Q它对不同的应用E序讄的cookie路径是不同的Q这样不同的应用E序所用的session (tng)id是不同的Q因此即使在同一个浏览器H口里访问不同的应用E序Q发送给服务器的session (tng)id也可以是不同的?br />
(tng) (tng)
Ҏ(gu)q个Ҏ(gu)，我们可以推测Tomcat中session的内存结构大致如下?br />
W者以前用q的iPlanet也采用的是同L(fng)方式Q估计SunONE与iPlanet之间不会(x)有太大的差别。对于这U方式的服务器，解决的思\很简单，实际实行h也不难。要么让所有的应用E序׃n一个session (tng)idQ要么让应用E序能够获得其他应用E序的session (tng)id?br />
iPlanet中有一U很单的Ҏ(gu)来实现共享一个session (tng)idQ那是把各个应用程序的cookie路径都设?Q实际上应该?NASAppQ对于应用程序来讲它的作用相当于根）(j)?br /><session-info>
<path>/NASApp</path>
</session-info>
需要注意的是，操作׃n的session应该遵@一些编E约定，比如在session (tng)attribute名字的前面加上应用程序的前缀Q得?tng)setAttribute("name", (tng)"neo")变成setAttribute("app1.name", (tng)"neo")Q以防止命名I间冲突Q导致互相覆盖?br />
在Tomcat中则没有q么方便的选择。在Tomcat版本3上，我们q可以有一些手D|׃nsession。对于版?以上的TomcatQ目前笔者尚未发现简单的办法。只能借助于第三方的力量，比如使用文g、数据库、JMS或者客L(fng)cookieQURL参数或者隐藏字D늭手段?br />
我们再看一下Weblogic (tng)Server是如何处理session的?br />
(tng) (tng)
从截屏画面上可以看到Weblogic (tng)ServerҎ(gu)有的应用E序讄的cookie的\径都?Q这是不是意味着在Weblogic (tng)Server中默认的可以共享session?jin)呢Q然而一个小实验卛_证明即不同的应用程序用的是同一个sessionQ各个应用程序仍然只能访问自己所讄的那些属性。这说明Weblogic (tng)Server中的session的内存结构可能如?br />
对于q样一U结构，在?tng)session机制本n上来解决session׃n的问题应该是不可能的?jin)。除?jin)借助于第三方的力量，比如使用文g、数据库、JMS或者客L(fng) (tng)cookieQURL参数或者隐藏字D늭手段Q还有一U较为方便的做法Q就是把一个应用程序的session攑ֈServletContext中，q样另外一个应用程序就可以从ServletContext中取得前一个应用程序的引用。示例代码如下，
应用E序A
context.setAttribute("appA", (tng)session); (tng)
应用E序B
contextA (tng)= (tng)context.getContext("/appA");
HttpSession (tng)sessionA (tng)= (tng)(HttpSession)contextA.getAttribute("appA"); (tng)
值得注意的是q种用法不可ULQ因为根据ServletContext的JavaDocQ应用服务器可以处于安全的原因对于context.getContext("/appA");q回I|以上做法在Weblogic (tng)Server (tng)8.1中通过?br />
那么Weblogic (tng)ServerZ么要把所有的应用E序的cookie路径都设?呢？原来是ؓ(f)?jin)SSOQ凡是共享这个session的应用程序都可以׃n认证的信息。一个简单的实验可以证明这一点，修改首先d的那个应用程序的描述Wweblogic.xmlQ把cookie路径修改?appA (tng)讉K另外一个应用程序会(x)重新要求dQ即使是反过来，先访问cookie路径?的应用程序，再访问修改过路径的这个，虽然不再提示dQ但是登录的用户信息也会(x)丢失。注意做q个实验时认证方式应该用FORMQ因为浏览器和web服务器对basic认证方式有其他的处理方式Q第二次h的认证不是通过 (tng)session来实现的。具体请参看[7] (tng)secion (tng)14.8 (tng)AuthorizationQ你可以修改所附的CZE序来做q些试验?br />
八、ȝ
session机制本nq不复杂Q然而其实现和配|上的灵zL却使得具体情况复杂多变。这也要求我们不能把仅仅某一ơ的l验或者某一个浏览器Q服务器的经验当作普遍适用的经验，而是始终需要具体情况具体分析?br />摘要Q虽然session机制在web应用E序中被采用已经很长旉?jin)，但是仍然有很多h不清楚session机制的本质，以至不能正确的应用这一技术。本文将详细讨论session的工作机制ƈ且对在Java (tng)web (tng)application中应用session机制时常见的问题?sh)出解答?img src ="http://www.aygfsteel.com/do4best/aggbug/68194.html" width = "1" height = "1" />
]]>
]]>
]]>