限制多窗口重复登陆

SecurityRegistry 只是一个接口，你可以去实现字节的，例如把数据存储到memcached中或者（tt+tc）
，默认是存储在当前jvm内存中，

我这是只是说了spring security的实现方式，你可以参考，没有必要非要把spring security整合进来

汗，貌似这个工程就大了，有些杀鸡用牛刀的感觉
我们现在是没有分布式缓存机制的。其实之前有同学提出存在ApplicaionContext里面，但就是不知道集群情况下是否会共享ApplicationContext

没有那么牛叉的功能吧，


在集群环境下同步就更难了，成本更大，memcached使用很简单，是比较好的实现方式。

   其实楼主换一个思路就能解决这个问题。其实我们理解的session已经包括了两个东西，一个是http session机制，而另外一个是实现servlet规范的JVM session存储对象。楼上如果将这两个理解区分开就能解决这个问题了。
    在很多具有分布式负载均衡的系统中，为了确保一个用户的多次访问都在同一个机器上（如果是不同机器就涉及到session复制），或者说能获取同一个session存储内容，都采取了加上jsessionId这样的url参数方式，它其实就是我前面讲的后者。
    楼主限制重复登录，其实只需要对后者进行管理控制，不需要关心前者是否会被创建.

好像服务器就是根据session id来判断是否是同一个用户的，如果是一有的seesion id，则会将请求分流到之前处理这个请求的节点上。现在的问题是session id在每次IE关掉之后在客户端都没有了，服务器没办法进行识别。
不知道我的理解是否正确

不知道可不可以将LZ的需求简化（一个服务器、一个应用）为?：
1、同一个用户ID，禁止其创建多个session会话。
2、同一客户端机器，依然允许登录多个不同的用户ID，但需满足第1点。

如果这样的话，我的方案是：
1、首先在应用层，是有办法可以记录该应用当前所有session会话的；
2、在1的基础上，在应用的最靠前的环节（在该环节，任何一次HTTP请求沿未导致新session会话的建立）设立过滤器（过滤每一次HTTP请求），就是在这过滤环节，判断当前session会话列表中是否包括该用户ID，如果是的话，则作出A和B中的其中一种决策：
   A、终止此次HTTP请求，请将错误信息响应给客户端，后续不再作任何处理；
   B、提示客户端，已有相同的用户ID登录，询问是否注销之前已有的同用户ID的session，并建立新的session会话（简单生硬一点的做法，干脆不“询问”，直接注销旧的session会话，然后放行此次请求）。

当然，这里的“询问”又是一个新的HTTP请求，这个请求主要包含两个关键信息，即“用户ID”及“登录密码”。

----------------------------
PS：LZ说使用到了集群，偶对多个Server间的session如何协同管理的没了解过。

在session这一层写个简单的map实现session缓存吧 这样下次就直接在缓存中查找相应session信息。

很简单的问题，为啥会有这么复杂的做法呢，建议楼主跳出现有的思路，重新设计吧。

一个application级的缓存就应该能解决楼主的问题了，如果群集可以借助jbosscache这样的缓存做简单的辅助就好。

   楼上其实说得是蛮对的，楼主换个思路就可以了。

   我们常说的session id是服务器判断与之相连接的客户端的会话，实质上，和我们另外一个角度理解的用户是有区别的。你说的没错，如果已经存在session，就转发。不过后面一句就陷进去了。其实我前面说过，你需要传递另外一个东西，jsessionId，你在很多网站都可以看到这种应用（尤其是IBM的），对于转发服务器来说，是否存在http session并不重要，没有创建一个就是。你session中存储的数据并不在其中，而是在你对应的JVM节点中，而它是可以通过jsessionId这样的方式去获取的。
   至于说怎么识别这样的东西，其实所有的支持负载均衡多个JVM节点并存的服务器都支持。或者大不了如楼上所说，自己建立中央缓存，自己在程序中识别这样的request参数。