java Session

Session：

Session的发明是为了填补HTTP协议的局限。请注意HTTP协议是通过用户发出请求，服务器作出响应的方式来工作的，这种用户端和服务器端的联系就是离散的，非连续的。HTTP协议不能提供允许服务器跟踪用户请求的功能。在服务器端完成响应用户的请求之后，服务器不能继续与该浏览器继续保持连接。从服务器这端来看，每一个请求都是独立的，因此HTTP协议被认为是无状态协议，当用户在多个主页间切换时，服务器无法知道他的身份。 Session的出现就是为了弥补这个局限。利用Session，您就可以当一个用户在多个主页间切换的时候也能保存他的信息。这样很多以前根本无法去做的事情就变得简单多了。

用户从到达某个特定的主页到离开为止的那段时间，每个用户都会单独获得一个Session。

Java Servlet定义了一个HttpSession接口，实现的Session的功能，在Servlet中使用Session的过程

（1） 使用HttpServletRequest的getSession方法得到当前存在的session，如果当前没有定义session，则创建一个新的session，还可以使用方法getSession（）

（2） 写session变量。可以使用方法HttpSession.setAttribute（name，value）来向Session中存储一个信息。也可以使用HttpSession.putValue（name，value），但这个方法已经过时了。

（3）读Session变量。可以使用方法HttpSession.getAttribute（name）来读取Session中的一个变量值，如果name是一个没有定义的变量，那么返回的是null。需要注意的是，从getAttribute读出的变量类型是Object，必须使用强制类型转换，比如：

String uid = (String) session.getAttribute("uid");

也可以使用HttpSession.getValue（name），但是这个方法也已经过时了。

（4） 关闭session，当时用完session后，可以使用session.invalidate()方法关闭session。但是这并不是严格要求的。因为，Servlet引擎在一段时间之后，自动关闭seesion。

 

 

//向session中添加数据  
request.getSession().setAttribute("warehouseout", list);  
  
//获取session中的数据  
List<ExchangeInOutBill> eInbill=(List<ExchangeInOutBill>) request.getSession().getAttribute("warehousein");  
  
//删除session中的数据  
request.getSession().removeAttribute("warehouseout")

 

http://www.cnblogs.com/tiechui/archive/2010/11/30/1892145.html

以下情况，Session结束生命周期，Servlet容器将Session所占资源释放：
1.客户端关闭浏览器
2.Session过期
3.服务器端调用了HttpSession的invalidate()方法。

"一个浏览器就是一个新session,关了浏览器session就结束了"
session 是在服务器端建立的，浏览器访问服务器会有一个sessionid，浏览器端通过sessionid定位服务器端的session,session的创建和销毁由服务器端控制。当浏览器关闭后，session还存在在服务器端，只不过你新开的浏览器去访问服务器会创建另一个session,这个时候的 sessionid已经不一样了。也就不能访问上一次的哪个session里面的内容了。 

"session的创建和销毁由服务器端控制",服务器端才有session,客户端只是通过sessionid来匹配session.
那服务器端session如何建的呢？ 普通html不会创建，jsp默认是创建的，只要你访问任何一个jsp就会创建（不过只创建一次），你关闭浏览器重新访问又会创建一个，这些创建的session由服务器自己控制销毁，你也可以在服务器端代码中销毁。

什么情况下需要用上这种服务器端的session方式？ 
默认情况下，jsp被访问就会创建session(最开始是空的没有数据的),你的应用中的代码只是往session里面put数据。网上说可以 通过 ＜%@ page session="false"%＞来不让jsp自动创session.我自己测试了一下（用sessionlistener），根本不起作用， session照样创建成功。
最后说一下，只有服务器端才有session.客户端被存到本地的是cookie.不过安全性低。所以不能放重要的数据。

============================================================================

sesion其实简单:
先request.getsession()，当已有一个session与前request相关时就返回对这个 session的引用，当没有时就生成一个.一个session在server通过一个sessionid来标识的。也就是说在一个server是不会有 两个相同sessionid的session.

那麼session为什麼会和cookie扯在一起呢?

正如我所说对於一 个session来说它的sessionid就是其身份的标识。若我们将这个sessionid保存到用户端，当同一个会话的后序请求来时都将这个 sessionid放在request 的header中(也就是我们说的cookie)这样不就可以来验证这个request是否与之前的request是同一个会话了吗!

什麼是会话呢?
我 们可以通俗一点理解。只要你的browers不关我们就称这一系列的request与response为一个会话。一断你close就称这个会话已结束。 虽然会话结束但并不代表你的session就被destroy.因为session是存活在server上的。它的生命完全由server来主宰 （web.xml中的设定）.
虽然你的session还存活在server上但你已无法再取得它。因为j2ee的api只给我们一种方法来取得与当前会话相关的session的引用:request.getsession() or reqeust.getsession(boolean)
=======================================================================

一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <%@page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);

这也是JSP中隐含的session对象的来历。

<**********************有点矛盾的地方,到底JSP显示的使用< %@page session="false"%>能不能让服务端不创建sessionid呢？试验下**************************&gt;
＜%@ page session="false"%＞ 
不是不让页面创建Session,而是在此JSP页面无法使用session.可以减少网络数据传输.

 

 

 

 

 http://alone-knight.iteye.com/blog/1611112

          在程序开发的时候, request session appplication内置对象, 是用的比较多的. request和appliction比较简单, 一个代表一次请求的生命周期. 另一个代表应用程序的生命周期. 多说一点application是单态模式. 在任何地方打印application内置对象,得到的是同一个地址. 因此可以存储程序的公共变量,而非个人的公共变量(个人的公共变量 例如登录信息) 应该存储到Session中

          今天我就详细讲解下中间那个兄弟. 因为在网上看到很多文章. 几乎毫无例外的说. 一个浏览器只有一个Session, 浏览器关闭Session就消失了.其实这种方法是不正确的.

          要了解Session首先要知道一个概念：Session的销毁只有两种情况：第一：session调用了 session.invalidate()方法. 第二：前后两次请求超出了session指定的生命周期时间. 其中Session的生命周期时间可以在web.xml配置. 默认30分钟 在web.xml可以做如下配置:

<session-config>
      <session-timeout>5</session-timeout>
</session-config>

        如何来证明关闭浏览器的时候Session没有销毁呢?  我们可以创建一个SessionListener 此监听器专门用来监听Session的生命周期的.代码如下：

 

别忘记在web.xml中配置监听器, 配置完毕后 可以做个测试. 当浏览器关闭后此监听器的 sessionDestroyed方法并没有执行,而是在5分钟左右(个人电脑没有那么精确) 才会触发sessionDestroyed ,当然 再打开浏览器的时候 sessionCreated 会自动调用 关闭5分钟后sessionDestroyed 又会自动调用, 通过getID方法大家可以判断是否为同一个Session. 所以网上说明的关闭浏览器Session就消失.其实并不正确. 如果没有任何配置的情况下. 关闭浏览器30分钟后Session才会消失的.

        我们可以利用这个概念做什么呢？ 最典型的就是利用 SessionListener  的sessionDestroyed方法 来记录用户非正常退出的时间. 用户在访问某个网站的时候(目前的银行网站都有此功能) 显示了用户的最后登录时间. 此时间如何获取. 在这里分两种情况

        如果用户按"退出" 按钮那就好说了. 跳转到action中.记录下用户退出的时间. 存储到持久层中

        如果用户非正常退出, 在没有配置Session的情况下 默认会在30分钟后调用sessionDestroyed 那么我们同样可以在此获取用户退出的时间,在sessionDestroyed 调用业务逻辑完成我们想要实现的功能

 

有关Session第2个典型的应用就是Session中存储了用户的登录信息. 那么就可以访问用户权限的一些页面.

       有关这个应用要注意一个问题: 存储到session中的 User对象一定要实现Serializable接口. Serializable的作用可以参考相关资料.正常情况下当我们做测试的时候关闭Tomcat 大家会在  Tomcat安装目录\work\Catalina\localhost\项目名 文件夹下面看到有一个 SESSIONS.ser 的文件.

 

 

此文件就是Session在Tomcat停止的时候 持久化到硬盘中的文件. 所有当前访问的用户Session都存储到此文件中. Tomcat启动成功后.SESSIONS.ser  又会反序列化到内存中,所以启动成功后此文件就消失了. 所以正常情况下 从启Tomcat用户是不需要登录的. 注意有个前提.就是存储到Session里面的user对象所对应的User类必须要序列化才可以.

 

 

可以对比下，从两篇文章可以看出：

过期的关键是 服务器端调用了HttpSession的invalidate()方法。
当时关闭浏览器后，服务器一般会马上调用这个方法

session其实就是一个特殊的cookie，

打开了浏览器后，
这个特殊的cookie就会保存在web服务器的硬盘上
并且浏览器和服务器一直在进行间断性的http通信，
当服务器侦测到浏览器关闭后
服务器端调用了HttpSession的invalidate()方法，
并且删除硬盘上的cookie。
有的不删除，为什么你重新登陆一个web网站，她知道你的个人爱好，因为她还保存你的cookie。

 

不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的Cookie，因此会共享一个Session。       注意：新开的浏览器窗口会生成新的Session，但子窗口除外。子窗口会共用父窗口的Session。例如，在链接上右击，在弹出的快捷菜单中选择"在新窗口中打开"时，子窗口便可以访问父窗口的Session。     如果客户端浏览器将Cookie功能禁用，或者不支持Cookie怎么办？例如，绝大多数的手机浏览器都不支持Cookie。Java Web提供了另一种解决方案：URL地址重写。    URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。HttpServletResponse类提供了encodeURL(String url)实现URL地址重写，该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。如果客户端不支持Cookie，则会将用户Session的id重写到URL中。    注意：TOMCAT判断客户端浏览器是否支持Cookie的依据是请求中是否含有Cookie。尽管客户端可能会支持Cookie，但是由于第一次请求时不会携带任何Cookie（因为并无任何Cookie可以携带），URL地址重写后的地址中仍然会带有jsessionid。当第二次访问时服务器已经在浏览器中写入Cookie了，因此URL地址重写后的地址中就不会带有jsessionid了。