hibernate中事务并发处理机制

1，事物并发时可能出现的问题：





2．数据库有自身的事务隔离机制：有4种分别是
          Read-uncommited在没提交之前也可以去读，但仍会出现dirty read，non-repeatable read，phantom read。
          Read-commited提交之后才可以去读，但仍会出现non-repeatable read，phantom read。
          Repeatable read当某条记录正在被使用时，会将它锁住，其它线程必须等它commit之后才可使用，可以有效避免各类事务并发问题。
          Serializable按顺序挨个执行，可以有效避免各类事务并发问题，但严重影响效率。

          Mysql默认的是repeatable read（查询方式select @@tx_isolation），如果想使效率提高可以使用read-commited，然后用hibernate去解决non-repeatable read等问题。
          Hibernate提供了悲观锁和乐观锁来防止事务并发导致的错误
               悲观锁：使用方式是在load（xx.class,i,LockMode.Upgrade）
                    a) LockMode.None表示无锁的机制，Transaction结束时，切换到此模式
                    b) LockMode.read在查询的时候hibernate会自动获取锁
                    c) LockMode.wrie在insert update时hibernate会自动获取锁
                    这三种锁都是由hibernate自行完成的，我们只需要写LockMode.Upgrade表示支持hibernate锁的方式即可。
               乐观锁：在表中增加一个字段，如果是使用annotation方式则在该字段的getter方法上加@version，如果是使用xml则加入<version name="version"></version>当出现事务并发错误时系统会提示错误，如
                      org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [domain.Account#1]

好贴，讲得很好了，对于高并发的大型系统的，定单处理很重要

请问这个和select 。。。for update no wait有啥区别呢，我决的完全通过hibernate框架无法阻止出现由于并发事务时导致的一系列问题，应该是程序结合for update no wait组合来处理并发事务问题，个人愚见。

version的乐观锁和LockMode的悲观锁都可以处理并发的。
只是select for update不是什么db都支持的

如果同时有多个应用在进行并行（并发）操作时，hibernate又如何解决事务一致性问题呢？

哪家的银行是这么设计的哈，就拿第一个案例来说lost update来说

一定是分为3个事务：存款1000，汇款100，取款100，每个事务都是记在借贷双方的，连传票都是起3份的。

呵呵 这不是孙卫琴的书上的吗？

楼主对sql 92事物隔离级别认识有错误：



1. repeatable read 仍可能造成phantom read；另外不要按自己的理解‘当某条记录正在被使用时，会将它锁住’，不同数据库事务隔离实现方式不一样，‘锁’的概念不能乱用。
2. serializable并不意味着按顺序挨个执行！ 即使使用serializable，数据库事物仍可能是并发的。