乐观锁在 集群环境或者多台服务器部署的情况下到底起不起作用？

碰到一个问题请教各位，Hibernate乐观锁对于集群环境或者多台服务器部署的情况下到底起不起作用？ 
我的理解是不起作用，但其他同事觉得起作用，大家想法不统一！ 
我理解的原因是：Hibernate的Update到实际体现的到数据库中总有一段时间差，如果另一线程在这时间差中又update了，将会导致两个 update都通过，而且后者覆盖前者的更新。 
希望各位解答下，顺便说明一下原因，谢了。 

7 个解决方案

#1

引用楼主 xiaobao552200 的回复:

我理解的原因是：Hibernate的Update到实际体现的到数据库中总有一段时间差，如果另一线程在这时间差中又update了，将会导致两个 update都通过，而且后者覆盖前者的更新。 

你的理解中没有乐观锁的东西吧。我觉得问题主要还是对乐观锁的理解上

#2

乐观锁是数据库层的概念，Hibernate最多在应用层启用了一下对应底层数据库的机制

楼主对乐观锁的理解有误，乐观锁是指在并发事务情况下，一个持有对象锁的事务"乐观"的判定其他事务不会影响到自己所涉及的对象，因此在自己事务过程中最大限度的释放掉锁以便其他事务获得，当然这个事务会有验证机制（比如重新query)

这样做的优势是提高并发性，劣势是当多个并发事务不幸就是在对同一数据操作（比如都对某一表的某一行数据做update)的时候，最先上锁的事务会遭遇大量的查询验证和重复执行

#3

引用 2 楼 qingyuan18 的回复:

乐观锁是数据库层的概念，Hibernate最多在应用层启用了一下对应底层数据库的机制

楼主对乐观锁的理解有误，乐观锁是指在并发事务情况下，一个持有对象锁的事务"乐观"的判定其他事务不会影响到自己所涉及的对象，因此在自己事务过程中最大限度的释放掉锁以便其他事务获得，当然这个事务会有验证机制（比如重新query)

这样做的优势是提高并发性，劣势是当多个并发事务不幸就是在对同一数据操作（比如……

如果像你所说的乐观锁是数据库级别的是不会有问题的，但要是乐观锁是数据库级别的，为何时还需通过hibernate来管理呢，我们直接通过数据库直接对某张表进行乐观锁设置就行了，但事实上我们没有这么做，或者是数据库级别的根本没有乐观锁的功能，或者是我的理解太肤浅了，只要你证明乐观锁是数据库级别的，那所有的问题都解决了。请前辈指教。

#4

引用 1 楼 lrbyantai 的回复:

引用楼主 xiaobao552200 的回复:
我理解的原因是：Hibernate的Update到实际体现的到数据库中总有一段时间差，如果另一线程在这时间差中又update了，将会导致两个 update都通过，而且后者覆盖前者的更新。


你的理解中没有乐观锁的东西吧。我觉得问题主要还是对乐观锁的理解上

乐观锁的机制其实就是update的时候再去查一次库，然后比较当前内存对象中的版本号与库里的是不是一致，如果一致就更新成功。
我的意思是说，一线程比较一致了然后也update了但由于是Hibernate管理的，所以并不能立即提交到数据库（中间肯定有时间差），这时间差中间又一线程（来自不同服务器JVM不同）来更新，然后乐观锁比较也通过了。。。
如果你能证明乐观锁是数据库级别而不是hibernate自己实现的，或者第一个线程的更新从Hibernate的更新到反应到数据库间没有时间差，那么命题就是成立的！

#5

请搜索关键字，for update (of)

这就是数据库级的

#6

引用 5 楼 lrbyantai 的回复:

请搜索关键字，for update (of)

这就是数据库级的

for update 对于hibernate来说是悲观锁，我觉得你应该指的是for update nowait
hibernate乐观锁用的就是这个，如果是这个的话，我觉得就没问题了！非常感谢!

#7

该回复于2011-04-29 08:32:44被版主删除