关于hibernate 的 长事务的问题


Session session1 = sessionFactory.openSession();
Employee employeeFromSession2 =
(Employee) session2.load(Employee.class, new Integer(employeeId));
session1.flush();
session1.connection().commit();
session1.close();


(a*)。。。。。。。。。。。。。。。。。
String newEmail = "something@different.com";
。。。。。。。。。。。。。。。。。。。。。。。。
employeeFromSession2.setEmail(newEmail);
session2.flush();
session2.connection().commit();
session2.close();

在web application中,当a 用户运行到了以上代码(a*)处 返回页面供用户修改,此时另外一个用户b 修改了同一个emplyee的name! 并提交。然后用户a 修改了email提交,作完后我发现b用户的提交又被a用户里的name(其实已经是脏数据了)复写回去了,b等于什么也没做。这样显得及不合理,不知道各位有什么好的解决办法,hibernate 里好像有version的,但不知道如何用,请教各位大虾

首先你的程序逻辑让我看不懂。我看不出来你的session1有任何用处。

其次,你是否想说的是,两个并发用户a和b,从数据库中load数据,此时a和b都拿到同样的数据。然后b先修改数据并且提交事务关闭session。此时a保持的还是原始的旧数据,然后a修改数据,之后提交数据库,这样把b用户修改的数据给覆盖掉了。

如果我理解你的意思是这样的话,我只能告诉你这根本不关Hibernate的事,任何ORM都无能为力,是数据库的事情,你要保证你想要的情况,必须修改数据库的隔离级别。

但是有一种情况,Hibernate不会修改数据库。假设a和b都load同样的数据,然后b修改数据提交数据库。此时数据库中是b修改后的新数据,a中是旧的数据,然后a用户在界面没有修改,之后a用户提交数据库。

在此种情况下,Hibernate会判断出a的数据没有被更新过,即使显式强制提交,Hibernate也不会向数据库发送sql,也就是说只要a的旧数据没有被修改过,并不会发生脏数据复写的问题。

我怀疑你想说的是后一种情况。

是这样的:一张表有两个字段 a b ,用户A 需要修改a 字段,用户B 需要修改b字段,那么 两个操作都需要先将字段抽出给用户看,然后用户在界面上作了修改,然后提交给服务器,更新数据库! 由于是同一张表 所以两个用户肯定用到的是同一个class的不同的实例,总是存在这样的可能用户A B 同时LOAD ! 然后显示给用户看,此时不可能保存事务,只有断开连接,然后再保存的时候,再连接 ,就有可能相互覆盖了,有什么好的解决方法?
我以前用过jbuilder 的dataexpress dataset它就可以监测出这种情况

对象version或timestamp,好像hibernate的doc上就有

你可以这样试试看,我没有试过,但觉得应该可以。

表的Mapping文件中a字段和b字段的映射,添加属性:


<property
name="propertyName"
column=
"column_name"
type=
"typename"
update=
"false"

/>

默认update属性是true,改成false以后,session.update(...)的时候,如果该字段对应的类属性没有修改,就不会出现在sql语句里面,应该就会解决你这个问题了。

http://hibernate.bluemars.net/hib_docs/reference/html/or-mapping.htmlor-mapping-s1-7

试过了,不行。update语句是在Hibernate的Configuration的时候生成的,不能动态改变。Hibernate只能做到对PO的状态管理,还不能细化到单独对PO属性的状态管理。虽然Hibernate不是没有解决办法,比如说自己写一个ClassPersister实现类,但感觉比较麻烦,不如直接用JDBC来的痛快。

其实你遇到的这个问题和事务没有什么关系,是一个PO状态管理的问题。ORM都是以Persistent Object为最小不可分割的可管理单元,所以如果碰到同一个PO的两个属性分别存在不同的状态的时候,ORM就无能为力了,就是用PO的version也没有用,version是针对PO的,不是针对单个属性的。

如果你不嫌麻烦,可以自己写一个ClassPersister实现类,不用全部自己实现,继承EntityPersister,覆盖一下其中update就可以了,主要根据修改了的属性产生update,那些没有改变的属性就不放到update里面。

如果怕麻烦,直接用JDBC得了。

我看了hibernate 生成的sql ,其实我觉得,hibernate 为什么不在update的同时,把原来的所有属性都加在where上呢?
比如update sampltable set a=newa where b = beloadedb ,当发现b 不是原先LOAD时的b 就抛出例外。(因为b有没有发生改变 那个类应该可以察觉到)。我注意到HIBERNATE的文档里有个关于VERSION的设置,但是不知道如何用,可能它是解决问题的方法?

在我做的项目中经常遇到此类问题!其实这是个同步的问题,最明显的就是订票系统,我觉得version或许是良方,你能给我具体讲讲version的作用么?

让我觉得奇怪的是hibernate为什么把没有改变过的属性也update那?难道他本身不是一种双层结构?load后作为原值,改变后的这另外存储,这样就可以对比出那些改变过,那些没有,如果一张表由40个字段,如果我只想更新一个却更新是不是很浪费数据库的资源?

或者我没有正确理解你的意思,或者你还没有搞清楚状况。

如果我确实正确理解了你的原来的需求的话,我还是要告诉你,这既不是事务管理的问题,也不是同步的问题,是一个状态管理的颗粒度的问题。Hibernate的状态管理细化到PO这一级,并没有细化到PO的单个属性(表字段)这一级。所以你不用白费力气了,这个问题看来属于那Hibernate不准备处理的5%。

PO的version只能跟踪整个PO的状态,一旦某个属性值改变,那么整个PO的状态就被标记,update的时候所有的字段一起更新。我原想设置映射文件的update属性应该可以解决属性更新的问题,但试过以后才知道不行。

你说的为什么update的时候所有的属性都一起update,而不是只更新改变字段,其实这是一个比较值得探讨的问题。

如果想要做到只更新改变了的字段,必须做到两点:
1、对PO的每个属性设置version进行状态跟踪
2、update语句是动态生成的,在实际向数据库更新的时候,依次检查每个属性的version,决定哪些属性需要更新,动态构造update语句。

单单要做到上述第一点,就势必要给PO的操作带来沉重的负担,每次属性的存取都要判断version,严重影响PO的性能。会带来整个Hibernate性能的降低。而要做到第二点,临时构造update语句时间消耗很客观,也会极大降低update的速度。

Hibernate的PO状态管理是当任何属性值改变的时候,version就被标记,表明PO被更新了。实现很简单而有效,效率非常高。而update语句insert,delete和某几个select语句是在Hibernate初始化过程中就构造好了,不需要用的时候临时构造。

综合评价得与失,对PO属性进行状态管理固然可以稍微降低数据库负担,但是会极大影响Hibernate的运行效率,终究得不偿失。

BTW,如果一个表有40个字段的话,那么这个表肯定会有多种复杂的关系,在这种情况下,你应该针对每种不同的关系映射不同的PO,也就是说,这张表会映射好几个不同的class,每个class代表不同的构成关系,每个class都只用到了这张表的某几个字段而已。class越细,可扩展性越好。

robbin, 这个是个很典型的需要使用optimistic transaction的问题,一般做法也就是用version检查了。

用户访问数据时,取到当前的version,当写入时,判断和先前的version是否相同,如果相同就更新并增加version,否则报错,程序可以根据错误,选择返回给用户,还是修改version后提交。

hibernate的做法是在object中加入一个version属性,version的赋值和判断都由框架管理,程序员不用自己操心。

在oracle中, 在第一个用户得到该记录后, 调用dbms_lock.request创建
一个lock, 完成任务后释放他, 其他用户检查这个lock, 如果存在就只能
查看, 不可修改.
dbms_lock的机制的优点是基于session的, 即使第一个用户的程序在中间
出错了, lock也会自动释放.

re guty:
optimitic transaction 是不是也不够保险,他只是把错误的概率降到最低,hibernate的version比较是取version的时候有没有用到for update ,这样可能会更好一点

想纠正一下两位大腕的说法:

To guty:

<<robbin, 这个是个很典型的需要使用optimistic transaction的问题,一般做法也就是用version检查了。<<

应该是optimistic lock

To Robbin
<<如果我理解你的意思是这样的话,我只能告诉你这根本不关Hibernate的事,任何ORM都无能为力,是数据库的事情,你要保证你想要的情况,必须修改数据库的隔离级别。<<

应该是事务的隔离级别.

希望没有说错