Hibernate在应用层对并发事务的控制

Hibernate与事务处理一文中，介绍了事务以及并发事务处理时的问题，和针对于这些问题在数据库层所能做的隔离级别，但是在选择read commit和repeatable read两个隔离级别时，如果考虑到performance和scalability，可以选择一个折衷的方案，也就是在数据库中的隔离级别选择read commit，而通过对应用程序的控制，可以达到repeatable read的效果。Hibernate在程序中控制并发的事务处理上，也有自己的方法，本文在Hibernate与事务处理基础上，对Hibernate的这些并发事务处理方法进行介绍。
数据库隔离级别可以通过设置hibernate的属性文件，来改变数据库默认的隔离级别：

在这里设置hibernate.connection.isolation=2;但需要注意的是，如果hibernate用在了应用服务器上，该应用服务 器对数据库连接提供了受管理的控制，则这里设置的isolation级别失效，采用的是app server定义的级别，可以通过改变app server的配置来改变该隔离级别。
因为这里设置的隔离级别是read commit，那如果想达到repeatable read，则需要设置version number或者timestamp。

如果某个项目从头到尾开始设计和开发，考虑到事务处理，则在需要并发控制的数据库表字段上，添加和hibernate的version number相对应的字段。例如对Student表的并发控制，则需要在TSTUDENT表上添加STU_VERSION字段，在ORM的映射文件中需要在标识符属性下添加，例如：

在Student.java的pojo文件中添加：

version属性是不能被应用所改变的，所以仅仅提供get方法即可。但是version number是怎样在应用层提供对事务的并发处理机制呢？原理是这样的：在hibernate的事务A（在这里假设事务的范围和Session范围一致，每个Session对应一个persistent context）中，执行每一个DML操作，都会先检查一下对象的version属性，假如从数据库中得到的student实例的version属性是1，此时student已经加载到Session对应的persistent context中，如果对student对象进行改变，在Session.flush()的时候，则将persistent context中的student对象的version属性设置为2，然后在保存student对象时，将对象对应的记录version字段更新为2。
注意的是，如果并发的另一个事务B在事务A进行保存操作之前，已经将version更新为2或者更高值的student存入数据库，那A在保存student之前，需要检查该persistent object对应的记录的version为1（因为在从数据库取得persistent object的时候，version为1）的行的个数，如果行数为0，则抛出 StaleObjectStateException，表明存在其他的事务更新了数据库，那这样的话，A事务的更新操作就不会覆盖B事务的更新操作，达到了避免（3）问题中的second lost update（见Hibernate与事务处理）。
当然避免了second lost update是不够的，因为是不是这样就能够具有repeatable read的隔离级别呢？比较一下read commit和repeatable read的隔离级别的差别，read commit是读事务允许其他事务并发执行，而repeatable read是读事务不允许写事务并发执行，在hibernate中，通过Session对应的persistent context来实现后者，具体是在一个事务A中(假设事务的范围和Session范围一致)，读取student对象到persistent context，此时事务B更改了student对象对应的记录并进行持久化，根据数据库的默认隔离级别read commit，那么A事务如果再读取student对象，那就是产生unrepeatable read，其实不然，正是因为hibernate的persistent context，使得A事务再次读取student不是从数据库中读取，而是从当前的Session读取，因此避免了unrepeatable read，同时使得具有类似于数据库隔离级别repeatable read的隔离效果。

当然我们这里假设的是事务的范围和Session范围一致，但是当用户操作中途停留时间过长，则需要将不同的事务在同一conversation下实现，要保证不同事务共用Session可以通过Hibernate的FlushMode来实现。当然也可以保证Session和事务的对应，通过在不同Session中传递detached object来实现。

对于Hibernate在应用层对并发事务的控制方法还有timestamp，pessimistic locking，这里先不做介绍。

如果有两个相关的对象，一个在hibernate缓存中，一个不在，有另外一个事务对两个对象都进行的更新，并提交，那还能读到两个对象一致的状态吗？


？？

这个问题就看hibernate的version number是怎么增加的，如果另外的事物对两个对象都进行更新，那么第一个事务所在的persistent context中的detached ojbect就是dirty data，如果第一个事务再次读关联对象时，如果被关联对象是lazy的，那么和数据库中的数据不一样，会产生异常，保证不读取两个不一致的状态。如果被关联对象不是lazy的，已经加载到persistent context中，那么第一个事物两次读取都从persistent context中读，应该是一致的。

你可以做个实验看看。

你怎么就不明白呢，如果有a、b两个对象，在第一个事务中先对a进行了读取，存到了它的缓存中。第二个事务对a、b对象都进行了更新，并提交了事务。然后在第一个事务再次对a、b进行读取，它可不会知道a已经被其他事务修改了，读的还是缓存中的a，而b在缓存中没有，所以直接读数据库，因为事务是read commited，所以能读到被第二个事务修改的值，那么a、b两个对象的值一个被修改前的一个是被修改后的，是不一致的，可能会影响业务。

如果事务级别是Repeatable read呢，不管第二个事务怎么修改数据，在第一个事务中后面读到a、b的值始终是第一次读取a当时时刻的值，也就是第二个事务修改前的值，a与b始终是一致的。

所以说hibernate能实现repeatable read的隔离效果这个说法是有问题的。

其实这和hibernate没有关系，即使在开始读取的时候，不可能一下全部把数据读出来，需要一个一个的读，在这期间也有可能后面的数据被其他事务修改了，导致和前面的不一致，所以，要实现Repeatable read的功能，还是要设置Repeatable read的事务隔离级别。

对于hibernate在应用一层所作的并发处理是持怀疑态度的，
Lock_mode最终还是落在数据库的transaction上，不同数据库的支持不一样。

version这些处理，觉得只是一些小技巧，但在不同的数据库平台，不同的事务隔离级别体现出来的效果不一样。而且要在业务逻辑中写代码去做判断和处理。

如果有a、b两个对象，在第一个事务中先对a进行了读取，存到了它的缓存中。第二个事务对a、b对象都进行了更新，并提交了事务。然后在第一个事务再次对 a、b进行读取，它可不会知道a已经被其他事务修改了，读的还是缓存中的a，而b在缓存中没有，所以直接读数据库，因为事务是read commited，所以能读到被第二个事务修改的值，那么a、b两个对象的值一个被修改前的一个是被修改后的，是不一致的，可能会影响业务。

你说的对，但是有没有其他方法用hibernate达到应用一层的repeatable read呢？如果使用数据库的repeatable read，那这样的话应用性能会降低。
如果没有这样的方法，那hibernate又是怎么样保证既不降低应用性能又能很好的处理并发事务呢？

hibernate使用version可以来解决多个操作同时对数据进行更新的问题，它是通过程序的处理来实现的，是脱离事务的，或者事务级别很低，你要把事务设成repeatable read，反而不好用了（是吧）。它只是用来解决并发更新的问题，与事务隔离级别实现的功能是不完全一样的。