为什么WebSphere经常会把我踢出来？(session失效）(100分)

我有时候在用WebSphere的时候会发现这样的问题。
如果一直是在一个IE窗口中操作，没有任何问题，但是如果你用window.open()
打开新窗口，或者是帧结构的，这个新窗口里的jsp有时候就得不到session中的值。
因为我在session中放了user对象，而每个叶面都根据user对象存在是否来判断权限，
用户在这种情况下得到的就是一个'you havn't logged in' 的出错叶面。
这个很令我伤脑筋。
解决这个问题可以用如下办法：按Shift-Ctrl-Esc,打开Task Manager,
关闭所有iexplorer.exe进程，然后再打开一个IE进程，重新登陆，就又好了。
这个问题发生在WAS3.02,3.5和4.0的各个版本中。
同样的程序在JRun中都是好的。
是不是我有什么设置有问题？
小猪来看看呀！

我想可能跟was的会话管理器有关，我怀疑是启用url重写和启用
cookie这两个设置。下面是我手上的关于会话管理器的资料，不知道
有没有帮助。
我没有写过jsp，想要写一个测试的jsp页面感觉无从下手。[]

6.6.11.1.4：会话管理器特性
允许溢出
指定驻留在内存中的会话数是否可超过“基本内存大小”特性所指定的值。
Ture－允许溢出
False－指定为基本内存中的大小以限制内存中的会话次数

当前允许溢出
表明“允许溢出”特性的当前值。
基本内存大小
指定内存中可存留的会话数。根据您使用的是驻留内存会话还是持久会话，情况将有所不同。
对于驻留内存会话，该值指定的是基本会话表中的会话数。使用“允许溢出”特性指定是否将限制整个会话管理器中的会话数为该值，还是允许在次级会话表中存储其它会话。
对于持久会话，该值指定了一般高速缓存的大小。如果启用了“高速缓存”特性，则基本内存大小将指定在会话管理器自动从数据库中读取会话更新之前，缓存更新会话的数量。
当您使用的是驻留内存会话、带有高速缓存的持久会话或用手工更新的持久会话时，该值不变。（手工更新高速缓存使用最后 n 个时间戳表示“最后访问”的次数，n 为“基本内存大小”的值）。
缺省值为 1000。如何定制该设置将取决于您的硬件系统、您站点的使用特征和为了使您的 Application Server 能容纳更大进程值而增加 Java 进程堆栈大小的愿意程度。

当前基本内存大小
表示了“基本内存大小”特性的当前值。
Cookie 注解
指定关于 Cookie 的信息。
Cookie 域
指定会话 Cookie 域字段的值。该值将限制发送 Cookie 的位置。例如，如果您指定了某个特定的域，则将仅发送会话 Cookie 到该域的主机上。
Cookie 最长寿命
指定 Cookie 驻留在客户机浏览器上的最长时间（以毫秒计）。该值应符合 Cookie 规范中所述的寿命值 (TTL)。
合法值：
以正整数表明寿命（以毫秒计）
-1 表明当前浏览器会话的 Cookie 一直存在
缺省值：-1
Cookie 名称
为该 Cookie 指定唯一的名称。
缺省值：sesessionid
Cookie 路径
指定将发送到会话 Cookie 的路径字段的值。指定值以限制发送 Cookie 所至的服务器路径。通过限制路径，您可以防止将 Cookie 发送到某些特定的小服务程序、JHTML 和 HTML 文件。
如果您指定根目录，在每次访问给定服务器时将发送 Cookie。
合法值：
所有表示服务器上路径的字符串
空白表明根目录 "/"

Cookie 安全性
指定会话 Cookie 是否包含安全字段。指定“是”以限制只对 HTTPS 会话进行 Cookie 交换。
当前状态
表明会话管理器当前所处的状态。当下一次启动时，它将更改为所期望的设置状态。
数据源
指定会话管理器获取数据库连接的数据源对象。
数据源表明数据库连接池以及其配置（例如，允许的最多连接数，即连接池的大小）。

当前数据源
表明当前所使用的数据源。
期望状态
表明会话管理器下一次启动时所应显示的状态。
启用 Cookie
指定会话跟踪是否使用 Cookie 携带会话标识。
True－会话跟踪将把到达的会话标识识别为 Cookie，并尝试用 Cookie 发送会话标识
False－会话跟踪将使用重写 URL 而不是 Cookie

启用持久会话
指定服务器关闭时是在数据库中保存会话数据还是丢弃会话数据。
True－会话数据存储在每个会话事务的数据库中
False－会话数据保留在小服务程序引擎的单个实例的内存中
为了使更改生效，该特性需要停止并重新启动与会话管理器相关的应用程序服务器。

当前启用持久会话
表明在关闭服务器时保存会话数据到数据库，还是丢弃会话数据。
启用协议转换重写
指定当 URL 要求从 HTTP 转换成 HTTPS，或从 HTTPS 转换成 HTTP 时，是否添加会话标识到 URL 中。
True－在 HTTP 和 HTTPS 之间转换需要会话标识
False－在 HTTP 和 HTTPS 之间转换不需要会话标识

启用会话
指定是否启用会话跟踪，即请求和响应对象的与会话相关的方法是否有效。
True = 会话管理器已启用
False = 会话管理器存在，但未启用

当前启用会话
表明当前是否启用了会话跟踪。
启用重写 URL
指定会话管理器是否使用重写 URL 来获取会话标识。若启用，则会话管理器将识别到达 URL 的会话标识，若有必要的话，还将重写 URL 以发送该会话标识。
失效时间
指定一个会话被视为无效前不允许使用该会话的时间长度（以秒计）。
合法值：
以正整数表示失效时间（以秒计）
-1 指定会话不会失效
缺省值：1800 秒（30 分）
为了保留性能，失效计时器无法精确到“秒”。可以放心地假设计时器精确到两分钟。
您应该清楚该设置和 Web 应用程序会话超时设置的关系。

连接数
指定最多可与数据库建立的并行连接数。
当前连接数
表明当前允许建立的、到数据库的最多并行连接数。
口令
指定用于访问会话数据库和表的口令。它只用在实现会话基本 Enterprise bean 中。如果已扩展了 Enterprise bean，则请在容器级为已扩展的 bean 指定数据库参数。
持久性类型
指定用于记录持久会话数据的机制。
合法值：
导入到数据库
Enterprise bean

当前持久性类型
表明当前正在使用的、记录持久会话数据的机制。
小服务程序引擎（或小服务程序引擎所选择的）
代表了与会话管理器关联的小服务程序引擎。
会话管理器名称
指定会话管理器的唯一名称。
启动时间
表明最近一次启动会话管理器的时间。
用户标识
指定用于访问会话数据库和表的用户标识。它只用在实现会话基本 Enterprise bean 中。如果已扩展了 Enterprise bean，则请在容器级为已扩展的 bean 指定数据库参数。
当前用户标识
表明当前用于访问用户会话数据源的用户标识。
使用高速缓存
指定是否维护内存中最近使用的会话列表。在某些情况下，该列表（高速缓存）可以帮助避免数据库的访问。
True－维护列表
False－无需维护列表
仅在启用持久会话和持久性类型是“直接导入到数据库”时应用该值。

当前使用高速缓存
表明是否维护内存中最近使用会话的列表。
使用手工更新
指定是否自动发送会话更新到数据库中。缺省情况下，Application Server 使用小服务程序最近一次访问所做的有效更改来更新数据库，例如，更新或除去应用程序数据。
使用手工更新，Application Server 会高速缓存最近的更新时间，并且会在会话无效性检查之前异步地更新数据库。对于其它更改，小服务程序书写器会使用作为对 HttpSession 的 WebSphere 扩展, com.ibm.websphere.servlet.session.IBMSession 的一部分所提供的同步方法，来更新自己。

False－Application Server 在小服务程序 service() 方法结束时自动更新数据库
True－小服务程序必须调用一个同步方法来手工更新数据库

仅在启用持久会话和持久性类型是“直接导入到数据库”时应用该值。

当前使用手工更新
表明当前是否正在使用手工更新。
使用多行会话
指定是否将应用程序数据的每个实例放置在数据库的不同行中，以使每个会话中可存储大量数据。在某些用法情况下，这可能会获得更好的性能。
仅在持久性类型是“Enterprise bean”或“直接导入到数据库”的情况下应用该值。

True－将应用程序数据的每个实例放置在数据库的不同行中
False－允许将应用程序数据的实例放置在相同行中

当前使用多行会话
表明是否当前正在使用多行会话。
使用本机访问
指定是否使用由 C 编程语言编写的，优化的基于 JNI 的 SQL 访问来执行会话持久性数据库更新。

True－使用由 C 编写的基于 JNI 的 SQL 来访问数据库
False－使用 JDBC 缺省值来访问数据库
仅当您使用 IBM DB2 作为数据库时该选项才有效。

当前使用本机访问
表明当前是否正在使用本机访问。

下面的东西可能是你想要的。
使用 URL 重写来维护会话状态，请勿从普通 HTML 文件（带有 .html 或 .htm
扩展名的文件）链接到您部分的应用程序。
因为普通 HTML 文件中无法使用 URL 编码，所以这种限制是必需的。为了使用
URL 重写来维持状态，用户在该会话期间所请求的每个页面都必须具有 Java 解
释器所能理解的代码。
如果会话期间用户可能访问的应用程序（或 Web 应用程序）或部分站点中含有这种
普通 HTML 文件，则请将它们转换成 JSP 文件。
这将影响到应用程序编写者，因为如上述描述，用 URL 重写维护会话要求应用程序中
的每个小服务程序必须对 <A> 标记上的每个 HREF 属性使用 URL 编码。
如果应用程序中的一个或多个小服务程序不调用
encodeURL(String url)
或
encodeRedirectURL(String url)
方法，则会话将丢失。

thanks!
看来是这个问题。
天啦...所有的代码都要改....
做个正则表达式去search ...
不过不知道为什么这个发生的概率非常低。大概100次window.open会有1次丢失会话。
俺看得是英文版的文档。

也许你同时使用了cookie和url重写。
要简体中文的文档吗？繁体的也有。
我在ibm站点上下的，太大了，发给你估计有点难。

使用IE6.0时，常常莫名其妙的死掉，打开的网页全部关闭，不知为什么？
环境是： win2000Server；

>使用 URL 重写来维护会话状态
如果我没理解错，应该是把sessionId之类的信息写在每个URL上。
IMHO，如果Cookie已经能够维护session了，那何必还要这个？
再说，如果换了URL方式就可以了，那多半也是Browser丢Cookie，
不是服务器的问题。我觉得这可能不是问题的根本。
你可以先试一下是不是有Cookie丢失的情况。

对，我就是怀疑新打开的窗口取不到cookie ...但是无法验证...
考虑到这个问题都是出在弹出的窗口之中,我总觉得是client端的问题，
和server无关，但是为什么别人写的程序几乎不出这样的问题呢？

如果你真有时间，我觉得最好的方法是找一个或者写一个HTTP代理，在代理上
监测是不是每个request都带有Cookie，这样可以看清楚到底是client还是server
的问题。
在Server短，写一个Servlet做“网关”，它接受所有的request（这个通过servlet
mapping可以实现），然后再根据request URL， forward到真正的servlet或JSP。
在这个“网关”servlet中枚举出所有的Cookie,Session,....,然后写到数据库。
通过上面的数据，应该可以分析出问题在那里。
我觉得问题可能在于没有时间这么做，所以只能Estimate，希望可以猜到问题的所在。
祝你好运！

如果只是client端的问题，为什么你的程序在jrun中又没有问题呢？
是否websphere的客户端cookie写入机制跟jrun有不同呢？还是
websphere本身有bug导致的呢？反正我觉得应该不仅仅是client的问题。

多人接受答案了。