随笔档案(496)

       在现在的B/S体系结构的软件开发中，对于数据库事务处理中最常使用的方式是每个用户请求一个事务。也就是说，当服务器端接收到一个用户请求后，会开始一个新的事务，直到对用户请求的所有处理都进行完毕并且完成了响应用户请求的所有输出之后才会关闭这个事务。

       对于使用Hibernate实现持久化功能的系统来说，事务的处理是这样的：服务器端在接收到用户的请求后，会创建一个新的Hibernate Session对象，然后通过该Session对象开始一个新的事务并且之后所有对数据库的操作都通过该Session对象来进行。最后，完成将响应页面发送到客户端的工作后再提交事务并且关闭Session。

       Session的对象是轻型的，非线程安全的，所以在每次用户请求时创建，请求处理完毕后丢弃。

       那么，该如何实现这种方式的事务处理呢？处理的难点在于如何在业务处理之前创建Session并开始事务以及在业务处理之后提交事务并关闭Session。对于现在的Web应用来说，通常情况下是通过ServletFilter来完成事务处理的操作。这样，就可以轻松地实现在用户请求到达服务器端的时候创建Session并开始事务，而服务器端响应处理结束之前提交事务并关闭Session。

       另外一个问题是，在ServletFilter中创建的Session是如何传递给业务处理方法中的呢？处理的方法是通过一个ThreadLocal变量来把创建的Session对象绑定到处理用户请求的线程上去，这样就可以使任何的业务处理方法可以轻松得到Session对象。

       Hibernate中事务处理的具体方法可以参照前面的网络博客的实例。

       但是这种事务处理的方式还是会遇到一些问题，其中最突出的就是更新冲突的问题。例如，某个操作人员进入了用户信息的修改页面，在经过一段时间的对用户信息的修改后，进行提交操作，而与此同时可能会有另外一个操作人员也进行了相同的操作，这样在处理提交的时候就会产生冲突。

       产生这个冲突的原因在于在开发中需要使用多个数据库事务来实现一个应用事务。也就是说，在应用程序层，应该将读取用户信息、显示修改页面以及用户提交工作来作为一个事务进行处理，在处理的过程中应该避免其他操作人员进行类似的操作。

       回想前面的介绍，我们对于数据库事务所采取的策略是每个用户请求一个事务，而上面的业务处理则至少需要两个请求才能完成。这样，两者之间就存在着一定的矛盾，这也就导致了不可重复读取和两次更新问题的发生。

       为了解决并发中数据访问的问题，通常会采用锁的机制来实现数据访问的排他性，从而避免两次更新问题的发生。