捕捉登出时间解决方案-----java中session的正确理解

 捕捉登出时间解决方案-----java中session的正确理解收藏
        前段时间要做一个捕捉用户登入和登出时间的功能，查了很多资料，做了很多测试，总结出两套方案，其中对session有了进一步的认识。

 

        用户的登入时间很好做了，在用户验证成功通过后，得到当前系统时间记录就行；如果系统用的是Acegi的话，可以写一个类，继承Acegi中的 AuthenticationProcessingFilter.java，并覆盖其onSuccessfulAuthentication方法，故名思意，这个方法就是acegi在对用户成功通过时进行的一个附加操作的方法，在这个方法里你可以记录当前用户id、时间、ip等等日志信息到数据库中。

 

        但要捕捉用户的登出时间确实是很麻烦，首先要知道是http是无状态连接协议，当用户不通过注销方法登出而直接关闭浏览器或者结束进程时，服务器根本无法捕捉这个事件，不管客户端发生了什么服务器也不知道，用户仅仅从服务器那得到了一个sessionid存储在浏览器进程的内存中或者cookie中，网上很多说用window.onunload( )等js方式来捕捉用户登出事件其实也其不通，因为用户可以直接杀死进程或者在新窗口页中打开链接，然后把原窗口关闭，这时通过js捕捉到关闭浏览器事件并发送请求告诉服务器，但其实用户还并没有离开系统，只不过换了个浏览器浏览页面。还有就是通过session过期来捕捉，但在系统正常运行下 session死亡只有两种可能：

1.session的持有者(即客户端浏览器)在最大无活动等待时间(MaxInactiveInterval)内无任何响应或请求  
2.session 被调用invalidate()方法强制弊而当用户关闭了浏览器后标志着session将不再发送请求到服务器，服务器也不会无缘无故调用它的 invalidate()方法，这样session只能等到time-out时才会销毁，如果系统设置了session的 MaxInactiveInterval为-1的话，那这个session将永远存活到服务器关闭为止。

所以session不能反应出用户的活动状态，浏览器关闭事件也不能完全得出用户一定是退出了系统。

 

     那这个登出时间到底怎样才能得到呢？事实如此，只能降低期望了，和老大讨论了许久，最后只有两套方案行得通，如下。

 

 一，以性能换精度，也是我最终采用的方案，我们可以精确地得到用户登入时间，而登出时间我们得到个大概的时间就行，不需要太精确，毕竟系统不是什么很机密性的东西。采用session监听器来实现，写一类，继承HttpSessionListener，实现其public void sessionDestroyed(HttpSessionEvent arg0) 和public void sessionCreated(HttpSessionEvent arg0) 方法，当用户session失效时会走sessionDestroyed方法，在其里面得到的当前时间就是用户的大概登出时间，前提是系统session 过期时间不能设置太长，要不误差就太大了，半小时就差不多。

 

二，以精度换性能，b/s系统的页面一般都会带有头部、脚部页面或者是框架型的，这样我们就可以在公用的头脚或主框架页中插入一个隐藏的iframe或者代码块。里头写一段js方法，window.setInterval()之类的，每隔一小段时间（假设为2分钟）向服务器发送一个空请求，目的仅仅是让服务器知道客户端还开着我的页面，不管是以哪种方式。服务器接受这个请求后，新建一个Map对象（新建一javabean类也行，里面有用户id和请求时间两个属性），put两个元素，当前用户id为value，一约定代号为key，如“userid”，另一元素请求时间为value，同样一约定代号为key，如“requesttime”；然后再以这个对象为value，sessionid为key ，set一个attribute到session当中，当下次再收到一个请求时，再重复上部操作，这样请求时间会不断更新。做完这些之后，还需要添加一个定时调度的job，每隔一小段时间（假设为3分钟），遍历session对象，从其中的map或者javabean中取出userid 和 requesttime，判断这个请求时间和当前时间的时差是否大于三分钟，如果是则说明用户已经没有再向服务器发送请求，即没有页面再用户端打开着，用户离开了，记录最后一次请求时间，也就是用户的登出时间。

 

       目前还没有想到其它更好的方法，现在这种机制下好像也只能这样了，还有一点需要注意，如果采用在用户登录成功时记录登录时间的方式，在要求并发数较大的时候不可行，今天对我们项目组做的一个系统进行登录过程50、100用户并发测试时，失败率极高，而问题就出在登录时向数据库记录登入时间和更新最高访问人数时出现的sql事务死锁情况，所以后来更换了方案，在登录时将当前时间为value,sessionid 为key，set到session当中，当这个session过期时，通过httpsessionlistener捕捉到该事件，从session中取出该用户的登录时间和当前时间一并存入数据库，后者作为登出时间；最高访问人数也放在了application里，这样性能上提高了不少。

 

        如果要得到用户的在线时间的话，需要注意的是，由于一个浏览器进程共用一个session，一个浏览器中的所有标签也是共用一个session，在用户登录成功时需要通过当前sessionid判断用户是否重复登录了，如果是则在此时就不应该将当前时间set到session中，而应该保持上次存储的登录时间。

 

 

/*********** 下面再引入一下网上比较经典的描述，更有利于理解session和cookie ************/

让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：
1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。
2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。
3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说 cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端

保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。