《Head First Servlets & JSP》-6-会话管理

容器怎么知道客户是谁

Http协议是无状态连接，客户浏览器与服务器建立连接、发出请求、得到响应，然后关闭连接。即，连接只针对一个请求/响应。
对容器而言，每个请求都来自于一个新的客户。

客户需要一个唯一的会话ID

IP不能唯一标示Internet上特定的用户
比如公司网络内的用户为一个IP；而IP地址也只是路由的地址；用户换了一台设备的情况；

客户和容器如何交互会话ID信息
容器必须以某种方式吧会话ID作为响应的一部分交给客户，而客户必须把会话ID作为请求的一部分发回；
最简单而且最常用的方式是通过cookie交换这个会话ID信息。
容器会做cookie所有的工作！
在响应中发送一个会话cookie：
HttpSession session=request.geteSession();

余下的所有事情都会自动发生：
你不用自己建立新的HttpSession对象；
你不必生成唯一的会话ID；
你不用自己建立新的Cookie对象；
你不用把会话ID与cookie关联；
你不用在响应中设置Cookie；
cookie的所有工作都在后台运行；

从请求得到会话ID：
HttpSession session=request.geteSession();
与为响应生成会话ID和cookie时所用的方法完全一样！
即：

if(请求包含一个会话ID cookie){
    找到与该ID匹配的会话；
}else if(没有会话ID cookie OR 没有与此会话ID匹配的当前会话){
    创建一个新会话；
}

若不想新建会话
HttpSession session= request.getSession(false);
若只想要一个已经有的会话，若没有会话则返回null，若有会话存在则返回HttpSession。
若用户不接受cookie
若用户没有启用cookie，则需要使用URL重写。在Tomcat中表现为URL+;jsessionid=1234567。
如果不能用cookie，而且只要告诉响应要对URL编码，URL重写才能奏效。

容器怎么知道cookie不能正常工作？
容器并不知道cookie是否工作，所以向客户返回第一个响应时，它会同时尝试cookie和URL重写这两种方式；
当用户发出下一个请求，它把会话ID追加到请求URL，若用户接受cookie，这个请求也会有一个会话ID cookie；
当servlet调用request.getSession()时，容器若从请求读取会话ID，则认为这个客户接受cookie，所以可以忽略response.encodeURL()调用。
另一种URL重写
response.encodeRedirectURL("/BeerTest.do");
用于想把请求重定向到另一个URL，但是还是想使用一个会话。

注意，若依赖会话，就要把URL重写作为一条后路；
另外，因为需要URL重写，就必须在响应HTML中动态生成URL，这意味着必须在运行时处理HTML。（当然，可以在JSP中完成URL重写。）
encodeURL()方法是HttpServletResponse对象上调用的方法，不能再请求上调用这个方法；URL编码只与响应有关。

关键的HttpSession方法

设置会话超时

会话有3中死法：

超时
在会话对象上调用invalidate()
应用结束（崩溃或取消部署）

在DD中配置会话超时

这与在会话上调用setMaxInactiveInterval()一样的效果。
设置一个特定会话的会话超时
cookie
cookie实际上就是用户和服务器之间交换的一小段数据（一个名/值String对）；
服务器把cookie发送给客户，客户做出下一个请求时再把cookie返回给服务器。
与cookie相关的方法封装在3个类中：HttpServletRequest、HttpServletResponse和Cookie。
cookie和首部

HttpSession对象的生命周期中的重要时刻：

注意，实现了HttpSessionBindingListener的属性类（如Dog类），不在DD中配置，因为它只与会话中的某个属性有关；
而HttpSessionListener和HttpSessionAttributeListener必须在DD中注册，因为它们会会话本身有关。

会话迁移【分布式Web应用的范畴】

分布式Web应用中，每次同一个客户做请求时，最后这个请求都有可能达到同一个servlet的不同实例；
即指向servlet A的请求A可能在一个VM中，而指向servlet A的请求B可能在另一个不同的VM中。
那么，ServletContext、ServletConfig和HttpSession对象如何表现？
答案：只有HttpSession对象（及其属性）会从一个VM中迁移到另一个VM中（即所有VM只有一个同样ID的HttpSession），其他对象复制（不同VM可能有多个这类对象）。

属性迁移
若属性是直接的Serializable对象，则该属性会自动在迁移时序列化，不用额外关心它。
若属性类型不是Serializable呢？那么为了迁移，需要让属性对象类实现HttpSessionActivationListener，并使用激活/钝化回调方法解决这个问题。

Listener示例

会话计数器
这个监听者允许你跟踪这个Web应用中活动会话的个数：

在DD中配置监听者：

注意：
属性监听者
这个监听者，当每一次向会话增加属性、删除属性或者替换属性时，都能被跟踪到。

在DD中配置监听者：

注意，System.out标准输出在Tomcat中默认输出到tomcat/logs/catalina.log中。
属性类（监听对它有影响的事件）