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

Question

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

Answer 1

乐观锁是数据库层的概念，Hibernate最多在应用层启用了一下对应底层数据库的机制楼主对乐观锁的理解有误，乐观锁是指在并发事务情况下，一个持有对象锁的事务"乐观"的判定其他事务不会影响到自己所涉及的对象，因此在自己事务过程中最大限度的释放掉锁以便其他事务获得，当然这个事务会有验证机制（比如重新query)这样做的优势是提高并发性，劣势是当多个并发事务不幸就是在对同一数据操作（比如都对某一表的某一行数据做update)的时候，最先上锁的事务会遭遇大量的查询验证和重复执行

Answer 2

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

Answer 3

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

Answer 4

请搜索关键字，for update (of)这就是数据库级的

Answer 5

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