session总结

5.2  Session机制
除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

5.2.1  什么是Session
Session是另一种记录客户状态的机制，不同的是 Cookie保存在客户端浏览器中，而Session保存在服务器上 。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
如果说Cookie机制是通过检查客户身上的"通行证"来确定客户身份的话，那么Session机制就是通过检查服务器上的"客户明细表"来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

5.2.2  实现用户登录

Session对应的类为javax.servlet.http.HttpSession类。每个来访者对应一个Session对象，所有该客户的状态信息都保存在这个Session对象里。Session对象是在客户端第一次请求服务器的时候创建的。Session也是一种key-value的属性对，通过getAttribute(String key)和setAttribute(String key，Object value)方法读写客户状态信息。Servlet里通过request.getSession()方法获取该客户的Session

5.2.3  Session的生命周期

Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里 。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。
Session在用户第一次访问服务器的时候自动创建 。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、 IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成 Session。
Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session 。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session"活跃（active）"了一次。

5.2.4  Session的有效期

由于会有越来越多的用户访问服务器，因此Session也会越来越多。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间 。如果超过了超时时间没访问过服务器，Session就自动失效了。

Session的超时时间为maxInactiveInterval属性，可以通过对应的getMaxInactiveInterval()获取，通过setMaxInactiveInterval(long interval)修改。

Session的超时时间也可以在web.xml中修改。另外，通过调用Session的invalidate()方法可以使Session失效。

5.2.6  Session对浏览器的要求

虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为JSESSIONID 的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session依据该Cookie来识别是否为同一用户。

该Cookie为服务器自动生成的，它的maxAge属性一般为-1，表示仅当前浏览器内有效，并且各浏览器窗口间不共享，关闭浏览器就会失效。因此同一机器的两个浏览器窗口访问服务器时，会生成两个不同的Session。但是由浏览器窗口内的链接、脚本等打开的新窗口（也就是说不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的Cookie，因此会共享一个Session。

注意：新开的浏览器窗口会生成新的Session，但子窗口除外。子窗口会共用父窗口的Session。例如，在链接上右击，在弹出的快捷菜单中选择"在新窗口中打开"时，子窗口便可以访问父窗口的Session。

如果客户端浏览器将Cookie功能禁用，或者不支持Cookie怎么办？例如，绝大多数的手机浏览器都不支持Cookie。Java Web提供了另一种解决方案：URL地址重写。

5.2.7  URL地址重写

URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id 。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。 HttpServletResponse类提供了encodeURL(String url)实现URL地址重写，例如：

 <td>  
     <a href="<%= response.encodeURL("index.jsp?c=1&wd=Java") %>">   
     Homepage</a>  
 </td>

 该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。如果客户端不支持Cookie，则会将用户Session的id重写到URL中。重写后的输出可能是这样的：

<td>  
     <a href="index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E?c=   
     1&wd=Java">Homepage</a>  
</td>

 

即在文件名的后面，在URL参数的前面添加了字符串";jsessionid=XXX"。其中XXX为Session的id。分析一下可以知道，增 添的jsessionid字符串既不会影响请求的文件名，也不会影响提交的地址栏参数。用户单击这个链接的时候会把Session的id通过URL提交到 服务器上，服务器通过解析URL地址获得Session的id。

如果是页面重定向（Redirection），URL地址重写可以这样写：

   <%  
       if("administrator".equals(userName)){  
          response.sendRedirect(response.
      encodeRedirectURL("administrator.jsp"));  
           return;  
     }  
 %> 

 

效果跟response.encodeURL(String url)是一样的：如果客户端支持Cookie，生成原URL地址，如果不支持Cookie，传回重写后的带有jsessionid字符串的地址。

对于WAP程序，由于大部分的手机浏览器都不支持Cookie，WAP程序都会采用URL地址重写来跟踪用户会话。比如用友集团的移动商街等。

注意：TOMCAT判断客户端浏览器是否支持Cookie的依据是请求中是否含有 Cookie。尽管客户端可能会支持Cookie，但是由于第一次请求时不会携带任何Cookie（因为并无任何Cookie可以携带），URL地址重写 后的地址中仍然会带有jsessionid。当第二次访问时服务器已经在浏览器中写入Cookie了，因此URL地址重写后的地址中就不会带有 jsessionid了。

http://book.51cto.com/art/200912/169764.htm

 

session的默认过期时间是20，可修改的最大时间是1440，可以在全局应用程序类中的void Session_Start(object sender, EventArgs e) 事件中用session.timeout设置过期时间


要知道session 原理以及生命周期
1：session 是通过浏览器的cookie来保存一个jessionid的信息 。这个jsessionid里面包含着你session 的id 。正是通过这个jessionid浏览器才能判断是不同用户的session ，用户每次进行session.getAttribute()或则 session.setAttribute时候。都会取出jesseionid里面的信息和session id比较。来区分不通的session。
2.session 的生命周期是一次会话。就是从用户开始请求这个application开始到application结束。 你停止了服务当然这个应用也就结束。tomcate容器出清除session

一般情况下，session都是存储在内存里，当服务器进程被停止或者重启的时候，内存里的session也会被清空，如果设置了session的持久化特性，服务器就会把session保存 到硬盘上。
你可以设置session的持久化特性试试看，当服务器进程重新启动或这些信息将能够被再次使用。
tomcat 正常关闭或者 restart 的话 tomcat 会在 work 的这个工程目录下有个 session.ser 文件，会保存在那里，重启时会重新加载。

默认的Tomcat是支持Session持久化的。当然，取消注释也就取消了这个功能。
conf/context.xml:
<Manager pathname="" />  .

Servlet容器通过在客户端浏览器中保存一个Session ID来跟踪Session，调用session.getID()可以看到你的Session ID是多少。如果客户端支持Cookie，就把Session ID作为Cookie保持在浏览器中，现在绝大多数浏览器都会把Cookie功能打开，但如果用户禁止了Cookie呢？Java Servlet API中提出了另外一种机制，Servlet容器可以重写客户requst的URL，把Session ID添加到URL信息中，HttpServletResponse接口提供了这样的方法：public String encodeURL(String url)－先判断如果没有启用Session，例如jsp中<%@ page session="false"%>或执行了session.invalideate()，那么直接返回url，在判断客户端师父支持 Cookie，如果不支持，就在url中加入Session ID的信息，然后返回修改后的url。

Session的管理
当一个sesson开始时，Servlet容器会创建一个HttpSession对象，在某些情况下把这些Httpsession对象从内存中转移到文件系统中或数据库中，需要访问的时候在把它们载入到内存中来。这样做的好处有两点：节约了内存的消耗，当web服务器产生故障时，还可以从文件系统或数据库中恢复Session的数据。

关闭浏览器并不销毁session,
只是打开新页面或提交新请求时,
获得是一个新的session，
而找不到原来的SESSION。

每个session都有个session id,
如果新的页面或新的请求附带着原来的SESSION ID，
那么就会找到之前的SESSION。
形如：
request.getContextPath()/login.do?jsessionid=XXXXXX