今天,在浑浑噩噩中,完成了第六章——【会话状态】的阅读,感觉很重要的一章!
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);
重要充实的第六章大餐品味完毕:)