Head First Servlets&Jsp 读书摘记4——【会话状态】

今天，在浑浑噩噩中，完成了第六章——【会话状态】的阅读，感觉很重要的一章！

37、Web服务器没有短期记忆。一旦发送了响应，Web服务器就会忘了你是谁。HTTP协议使用的是无状态连接（P221, 228）；

38、____________ _____________

|相同的客户 | |不同的客户 |

|相同的servlet| |相同的servlet |

|不同的请求 | |不同的请求 |

|不同的线程 | |不同的线程 |

|相同的会话 | |不同的会话 |（P226~227）；

39、对客户的第一个请求，容器会生成一个惟一的会话ID，并通过响应把它返回给客户。客户再在以后的每一个请求中发回这个会话ID。容器看到ID后，就会找到匹配的会话，并把这个会话与请求关联。（P229）；

40、最简单最常用的方式是通过cookie交换这个会话ID信息。

尽管原先设计cookie是为了帮助支持会话状态，不过也可以使用定制cookie来完成其他的工作。要记住，cookie实际上就是在客户和服务器之间交换的一小段数据。（P230, 248）；

41、如果客户不接受cookie，可以把URL重写作为一条后路。把会话ID附加到访问应用的各个URL的最后。 URL + ;jsessionid=856564543

如果不能用cookie，而且只有告诉响应要对URL编码，URL重写才能凑效。必须通过响应对象的一个方法（encodeURL()或encodeRedirectURL()）来运行所以URL，其他所有事情交给容器搞定。（P235~237）；

42、根本不能对静态页面完成URL重写！使用URL重写只有一种可能，就是作为会话一部分的所有页面都动态生成的！显而易见，不能硬编码会话ID，因为ID在运行时之前并不存在。（P237too）

43、会话有3种死法：

→超时

→你在会话对象上调用invalidate()

→应用结束（崩溃或取消部署）

（P243）；

44、上一页上所列的事件都是会话生命周期中的关键时刻。HttpSessionBindingListener则对应会话属性生命周期中的关键时刻。

如果一个属性类（如Dog类）实现了HttpSessionBindingListener，当这个类的一个实例增加到一个会话或从会话删除时，容器就会调用事件处理回调方法（valueBound()和valueUnbound()）。就这么简单，它自己会工作的。但是前一页上其他与会话相关的监听者必须在DD中注册，因为它们与会话本身相关，而不是与会话中放置的单个属性相关。（P254）；

45、每个VM有一个ServletContext，每个VM上每个servlet有一个ServletConfig。但对于每个Web应用的一个给定的会话ID，只有一个HttpSession对象，而不论应用分布在多个VM上。

跨VM涉及到会话迁移（钝化和激活）（P255~256）；

重要充实的第六章大餐品味完毕:)