标签：session

分布式cookie-session的实现(spring-session)

本文使用的spring-session版本为 1.0.0，地址为: https://github.com/spring-projects/spring-session

1     session存储策略

存储，即在后台使用session的setAttribute,getAttribute等方法时，这些内部存放的数据最终存储至什么位置。比如在默认的tomcat实现中，相应的数据即存储在内存中，并在停止之后会序列化至磁盘中。
可以使用内存存储和第三方存储，如redis。对于集群式的session存储，那么肯定会使用第三方存储的实现。

在spring-session中，对session存储单独作了一个定义，但定义上基本保证与http session一致，主要的目的在于它可以支持在非http的环境中模拟使用。因此不直接使用http session接口。
先看定义：

public interface Session {
     /** 获取惟一的id,可以理解为即将每个session当作一个实体对象 */
    String getId();
   <T> T getAttribute(String attributeName);
    Set<String> getAttributeNames();
    void setAttribute(String attributeName, Object attributeValue);
    void removeAttribute(String attributeName);
}

从这个定义来看，如果要使用httpSession，如果实现了这个session接口，那么实现上就可以全部实现httpSession对于存储的要求。对于非httpSession场景，使用这个也可以达到session存储的目的。
当然，为了保证在会话场景中会使用到失效，最后访问时间，最大不活跃时间的目的，spring-session也有一个继承于session接口的expiringSession接口。

1.0    id主键的生成

对于id，即理解为session实体对象惟一键，可以采用任意的一种惟一key生成策略。比如，使用uuid来生成惟一键。同时，也可以将这个id认为就是在http中sessionCookie的值

继续阅读“分布式cookie-session的实现(spring-session)”

会话Cookie及session的关系(Cookie & Session)

在通常的使用中，我们只知道session信息是存放在服务器端，而cookie是存放在客户端。但服务器如何使用session和客户端之间进行通信，以及jsessionId是怎么回事，这并没有一个完整和正确的认识，因此这里将这类信息汇总。

session中的jsessionId是在session创建好之后，发送给客户端。然后在每一次请求中，客户端即会将这个信息传递给服务器端，服务器端使用这个信息来维护和客户端之间的会话通信，在浏览器关闭之后，这个session就消失了。
而对于普通的cookie来说，它是有着一定的时间存放在客户端的机器中的。当下次打开浏览器时，这个cookie就会被读取，同时在请求时发放到服务器端。在关闭浏览器，这个cookie仍然存在的，并没有消失。
那么，这两者之间有没有联系呢，这就要看官方对于Cookie的不同分类，其实就对应着session Cookie和psersistent Cookie的描述了。如下所示：

Session Cookie
A user's session cookie[15] (also known as an in-memory cookie or transient cookie) for a website exists in temporary memory only while the user is reading and navigating the website. When an expiry date or validity interval is not set at cookie creation time, a session cookie is created. Web browsers normally delete session cookies when the user closes the browser.

Persistent cookie
A persistent cookie[15] will outlast user sessions. If a persistent cookie has its Max-Age set to 1 year (for example), then, during that year, the initial value set in that cookie would be sent back to the server every time the user visited the server. This could be used to record a vital piece of information such as how the user initially came to this website. For this reason, persistent cookies are also called tracking cookies.

从上面的描述中看，所谓的session Cookie，就是我们所说的session，其实就是一个没有设置过期时间的cookie信息。而普通的cookie，即我们通常所说的cookie，就是设置了过期时间(有效时间,通常大于一个特定的值,如一周)的cookie。

那么，我们可以这样认为。session就是服务器端，通过使用session Cookie来维系客户端和服务器的关系，而所谓的存储就是在服务器端针对这个session值(如jsessionId值)作了一个内部的增强，可以围绕着这个session Cookie创建一个单独的数据存储器(如map),然后来实现我们所谓的session数据存储呢。既然这样，在一些特定的场景(如分布式环境)，是否可以按照这种设计思路设计另外的session存储呢，这也是可以的。

继续阅读“会话Cookie及session的关系(Cookie & Session)”

从源码上分析hibernate的load和get之间的区别

一说到hibernate的get和load之间的区别，大多数网上的都会说出如下的区别：get不走缓存，load走缓存；或者get不会使用二级缓存之类，然而这些都是错误的。其实两者没有大多的区别，真正的区别在于二者获取对象的方式，以及如何使用对象上。本文从源码分析上分析两者的具体区别。本方使用的hibernate 版本为3.6.3。

获取对象的API，二者都使用统一的方式调用，如下所示：

来源于sessionImpl
		load的api:
                LoadEvent event = new LoadEvent(id, entityName, false, this);
		fireLoad( event, LoadEventListener.LOAD );
                
               get的api:
		LoadEvent event = new LoadEvent(id, entityName, false, this);
		fireLoad(event, LoadEventListener.GET);

可以看出，二者的api都一样，主要的不一样在于，触发事件的方式不一样。load时使用LoadEventListener.LOAD而get时使用LoadEventListener.GET。我们看看两者的具体不一样：

public static final LoadType GET = new LoadType("GET")
			.setAllowNulls(true)
			.setAllowProxyCreation(false)
			.setCheckDeleted(true)
			.setNakedEntityReturned(false);
	
	public static final LoadType LOAD = new LoadType("LOAD")
			.setAllowNulls(false)
			.setAllowProxyCreation(true)
			.setCheckDeleted(true)
			.setNakedEntityReturned(false);

主要的区别在于：在allowNulls上get允许而load不允许，allowProxyCreation上get不允许而load允许。具体这两者的区别在哪儿，我们进一步地从源码上进行分析。

继续阅读“从源码上分析hibernate的load和get之间的区别”

运用swfupload进行文件上传并支持java后台session验证

    我们都知道普通的文件上传是通过表单进行文件上传的，还不能达到异步上传的目的。通过使用某些技术手段，比如jquery form.js可以达到异步上传的目的，但最重要的问题在于，它不能够进行多个文件的上传。如果你要上传多个文件，必须一个一个地上传，同时还要在界面上处理当上传完一个文件之后，下一个文件上传框的问题。
    现在我们有了一个更多的运行，即使用swfupload进行多文件异步上传。顾名思义，它是一个flash的上传工具，但在界面上的表现形式使它和普通的html元素一样，没有复杂的展现，就一个普通的上传框，即可达到想要目的。

    关于swfupload的使用这里自不必多，这里主要介绍的是解决在java web开发过程中经常碰到的验证失败的问题。这是因为flash在上传的时候使用的是和浏览器不同的会话，这样就导致服务器在验证时自然被认为是新会话，从而验证不能通过，导致上传不能成功了。
    解决问题的方法，就是让flash在上传文件的时候带上同在一个界面的session标识，这通常是修改其中的upload_url来达到我们的目的，修改如下所示： 

upload_url: "/admin/infobuild/image/upload.q;jsessionId=<%=session.getId%>"

继续阅读“运用swfupload进行文件上传并支持java后台session验证”

javaEE开发中使用session同步和token机制来防止并发重复提交

    通常在普通的操作当中，我们不需要处理重复提交的，而且有很多方法来防止重复提交。比如在登陆过程中，通过使用redirect，可以让用户登陆之上重定向到后台首页界面，当用户刷新界面时就不会触发重复提交了。或者使用token，隐藏在表单中，当提交时进行token验证，验证失败也不让提交。这都是一般的做法。

    我们这次碰到的问题是重复提交本身就是一个错误，重复提交会导致一些相关数据的逻辑不再正确。而这些重复提交并不是通过普通的刷新界面，或者两次点击按钮来进行的。在普通的操作当中，我们可以通过一系列的手段，使得相应参数被清零，从而防止数据上的不正确。但是，在一种情况下，这些手段都不再有效，那就是并发的重复提交。
    并发重复提交，那就是在同一时间内（时间间隔可以缩短到0.X秒之内），在这种情况下，所有的常规逻辑都不再有效，因为多个请求，同时进入系统，系统已不能判断出这些请求是否是无效的，它们同时通过常规的重复逻辑判断，并最终在同一时间内将数据写入到数据库中，引起数据错误。

    举一个简单的例子，在系统中销售一个商品，首先通过该商品id进入到系统逻辑判断，判断此商品是否已售出，如果未售出，就进行数据存取操作。商品是否售出，是一个逻辑判断，是验证数据存储到数据库的一道门。在常规的判断当中，前一请求通过这道门之后，后一请求就不能通过了，因为验证为false。但在并发请求中，两个或多个请求同时通过了这道门，因为都是同时进入到判断，在判断之前都验证商品没有被售出，所以就同时进入到数据的存储当中。

    在常规的java开发中，对于这种情况，临界资源，通常是使用加锁来保证这种情况的先后顺序。但是加锁有一个问题即是，它是对于全局信息的加锁，即对整个将要销售的商品进行加锁了。对于BS应用来说，我们必须保证另一个操作人员的同一种商品的销售请求通过，即只限制同一个操作人员销售的并发请求，不限制多个操作人员不同请求的处理。
    在这种情况下，我们的加锁就不能简单的锁定在商品上，而是要锁定在与操作人员有关的信息上，这就是session。

    session是一个在单个操作人员整个操作过程中，与服务器端保持通信的惟一识别信息。在同一操作人员的多次请求当中，session始终保证是同一个对象，而不是多个对象，因为可以对其加锁。当同一操作人员多个请求进入时，可以通过session限制只能单向通行。
    本文正是通过使用session以及在session中加入token，来验证同一个操作人员是否进行了并发重复的请求，在后一个请求到来时，使用session中的token验证请求中的token是否一致，当不一致时，被认为是重复提交，将不准许通过。
    整个流程可以由如下流程来表述：

  1. 客户端申请token
  2. 服务器端生成token，并存放在session中，同时将token发送到客户端
  3. 客户端存储token，在请求提交时，同时发送token信息
  4. 服务器端统一拦截同一个用户的所有请求，验证当前请求是否需要被验证（不是所有请求都验证重复提交）
  5. 验证session中token是否和用户请求中的token一致，如果一致则放行
  6. session清除会话中的token，为下一次的token生成作准备
  7. 并发重复请求到来，验证token和请求token不一致，请求被拒绝

继续阅读“javaEE开发中使用session同步和token机制来防止并发重复提交”

通过query解析hibernate中的resultTransformer

    任何包装jdbc的框架，都离不开将最终的数据封装成java对象的一个过程。在jdbc中，取得的数据被封装在resultset中，通过迭代resultset来一次次的取得相应的字段和数据值。数据库框架始终需要解决的问题在于将resultset中的字段名称信息和相应的字段值对应起来，然后封装成对象，最后将所有的对象形成一个集合，并最终返回给调用者。
    任何数据库框架都逃不过这中间的处理逻辑，只不过如何将这些逻辑分散在上下的处理中。在Hibernate中，同样也有类似的东西，这个接口就叫做ResultTransformer。

    Transformer的定义如下：

public interface ResultTransformer extends Serializable {

	public Object transformTuple(Object[] tuple, String[] aliases);

	public List transformList(List collection);
}

    其中第一个方法transformTuple，即是如何处理从数据库查询出来的字段值（可能经过了二次处理）和相对应的字段名称值，比如将字段值和字段名称组合成一个map。字段值，即在查询过程中查询的字段列表，而字段名称即是在查询时select的名称。
    第二个方法transformList，提供了对于从数据库返回结果，进行了封装之后，再对封装之后的数据列表进行最后一次处理。如进行去重等。

    为了说明ResultTransformer在Hibernate中的运用，我们从Hibernate中的查询入手，看ResultTransformer如何在其中运用的(以Hibernate3.6.3版本为例，在代码中不显示不必要的代码)。

继续阅读“通过query解析hibernate中的resultTransformer”