熬之滴水穿石：Servlet--Web万物之源(6)

                                       30--会话

Web浏览器发请求给服务端，在通讯的方式中是属于短连接的也是无状态连接的方式。也就是说一旦服务器作了响应给客户端，它马上就会与客户端失去了联系。你再次连接上来时，它根本是不会去管你之前其实是和它有过联系的。所以对于Servlet处理这种情况便引出今天的话题：会话！

 

是的，是的!在Servlet中我们必须知道怎么去管理这个会话管理。通常我们会把一个对象保存在一个会话对象中，以及从会话对象中获取对象。然后在合适的场景中去创建会话对象，然后撤销会话对象。当然我们肯定需要使用会话监听，通过触发的事件做相应的处理。HttpSession这个对象能够保存与客户端在整个会话期间的会话状态，这是一种能在会话期间持久存储机制。好吧！我们一起就会话过程走一遍吧！

 

客户端发来的请求到Web服务端，容器找到Servlet并且分配一个线程发出请求把一个属性保存在相应的会话对象中。当Servlet处理完相应的业务逻辑后，将响应返回给客户端。此刻当客户端再发请求过来时，容器会让Servlet分配一个新的线程并且把一个属性保存在会话对象中。此刻是相同的客户，相同的Servlet，不同的客户请求，不同的线程，但它们都在一个相同的会话里面。两次不同的请求能关联同一个会话的话，是需要一个唯一的会话ID的。这些都是容器的事情，客户的第一个请求都会产生一个唯一的会话ID，并且通过响应把它返回给客户，客户再发请求中都会包含着这个ID。容器就会根据这个ID找到匹配的会话和相应的请求了。

 

这个会话ID通常我们可以让一个Cookie对象来保存。当请求来的时候，创建新的cookie对象，把会话ID保存在cookie中。容器就是从cookie中找到会话ID，并将这个会话ID与一个现有的会话匹配起来，并又和当前的请求关联起来。Cookie对象都是由容器自己完成。当然Cookie的使用时由客户自行决定，当客户不使Cookie时，会话又该如何完成呢？办法是有的，虽然大多数浏览器都使用了Cookie方式，当然除此之外还有一种办法就是采取URL重写的方式，我们可以在一些应用的URL看到有jsessionid=xxxx这样的情况。这就是没有依赖cookie所作的URL重写工作。每个链接都会有一个额外的信息以会话ID的方式附在后面，容器通过这些额外的信息去查找匹配的会话。Cookie方式保存会话ID和URL重写在容器上基本上都是同时会做的两件事情，当Cookie方式不使用时，便可以用URL重写。这个方法便是encodeURL（）或是encodeRedirectURL（）两个方法。

 

会话是一个很是占用资源的方式，由于请求都是无状态的连接。所以对于Web服务并不知道什么时候，该客户会不需要会话。在HttpSession接口中实现kill掉会话通常有3种：超时自己over，编码在会话对象上调用invalidate（）方法，在结束时自己取消。会话超时一般在web.xml文件里的<session-timeout>标签中配置。

 

好了，快到会话最为关键的部分了。那就是如何用监听的方式融入到会话的生命周期中去。在之前我们也提起过监听的8类方法，有几个方法正是用于会话生命周期中的。当创建会话或者是撤销会话时，一般可用HttpSessionListener。当会话属性需要增加或是删除，替换时可用HttpSessionAttributeListener。还有之前提起过的HttpSessionBindingListener了，这是让属性自己都知道什么时候加入会话或者从会话中删除掉的。

 

会话在现在运用最多的应属在分布式的Web应用中吧！像多台机器运行同一个web服务，通过负载均衡来处理客户的请求。在这样的环境中就可能会出现，第一个请求在A机器上，第二个请求在B机器上。然而建立在第一个机器上的会话要迁移到B机器上来，甚至还会有多次迁移的可能。这里就需要HttpSessionActivationListener监听了，这个监听能够让属性知道在什么时候会话的一部分迁移到另一台机器上去了。这里我说的机器应理解是JVM更为贴切。关于会话就说到这里，下一章节我们将说说Cookie.......

                                                 (未完待续........)