用户A发送一个请求，服务端保存其session数据，把服务器标识写到用户A的浏览器
1：如果用户A很长时间没有操作，也没有关闭浏览器，超时了，服务器把他的session删除了
2：如果该服务重启了，session数据丢失了
这两种情况，用户A在发送请求时，cookie中的服务器标识使他到达先前的服务，但是找不到数据了。
在weblogic websphere中怎么处理这两种情况是报错还是把这个当作用户A的第一次登陆处理的
[b]问题补充：[/b]
那如果是有session复制的 大概的处理流程是这样的吗
1：超时了，主备两个服务上的都把A的session删除了；A再发请求，这个是要先后调用主备服务查询之后才确定session没有了，当作第一个登录处理吗
2：主服务重启丢失了A的session；A再发请求，在主服务上找不到，去备份服务上找，找到了。。。
对于这种情况，所有的服务器都会当将用户认为是还未登陆的情况的，并要求重新登陆。
不然你一个过期的session，随便伪造一个session的话服务器都认为你登陆了，那问题就大了。
session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。
但程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否包含了一个session标识－称为session id,如果已经包含一个session id则说明以前已经为此客户创建过session，服务器就按照session id把这个session检索出来使用(如果检索不到，可能会新建一个，这种情况可能出现在服务端已经删除了该用户对应的session对象，但用户人为地在请求的URL后面附加上一个JSESSION的参数)。
如果客户请求不包含session id，则为此客户创建一个session并且生成一个与此session相关联的session id，这个session id将在本次响应中返回给客户端保存。
保存session id的几种方式
A．保存session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
B．由于cookie可以被人为的禁止，必须有其它的机制以便在cookie被禁止时仍然能够把session id传递回服务器，经常采用的一种技术叫做URL重写，就是把session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。
C．另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。
如何使用会话累计用户的数据
使用可变的数据结构，比如数组、List、Map或含有可写字段的应用程序专有的数据结构。通过这种方式，除非首次分配对象，否则不需要调用setAttribute。例如
HttpSession session = request.getSession();
SomeMutableClass value = (SomeMutableClass)session.getAttribute(“someIdentifier”);
if(value = = null){
value = new SomeMutableClass(…);
session.setAttribute(“someIdentifier”,value);
}else{
value.updateInternalAttribute(…); // 如果已经存在该对象则更新其属性而不需重新设置属性
}
看应用本身的设计了，可以考虑把数据存入数据表中，已sessionId为标识。cookie永不失效或者很久才失效。
在session中记录的时候就可以先检查是否重复在记录下当前的记录
楼上在说的session指的都是客户端的session，客户端的session可以通过cookie啊，表单隐藏域之类的手段保持在客户端，但是！
楼主列出来的情况是，服务器端session已经丢失了，那客户端是无法再登陆了的。
如果你用了主跟备，2个服务器，那就要求2个服务器只能产生1个session，并且2个服务器都是可以共同访问得到的。产生2个session那就是不同的会话了。这就要求主跟备要有文件共享，才能共享session，简单的复制机制是不行的。可以将session放在memcache中，这样各个服务器就可以方便地访问同一个数据源，获取相同的 SESSION 数据了。
具体你可以参看一下：
[url]http://www.91linux.com/html/article/program/php/20081224/14940.html[/url]