一、Hibernate处理事务并发问题
事务并发问题以前都有讲到过，可以翻阅以前的笔记。 在Hibernate中设置事务的隔离级别。 <property name="hibernate.connection.isolation">2</property> 隔离级别代号。 1：Read Uncommitted 2: Read Committed 4: Repeatable Read 8: Serializable
二、数据库系统锁的基本原理
为了避免各种并发问题，以保证数据的完整性和一致性，数据库系统采用锁来实现事务的隔离性。
锁的类型
-共享锁：用于读数据操作。允许其他事务同时读取资源，但不允许其它事务更新。
-独占锁：用于修改数据的场合。它锁定的资源，其他事务不能读取也不能修改。
锁的基本原理如下
-当一个事务访问某种数据库资源时，如果执行select语句，必须先获得共享锁。
如果执行update、insert、delete语句，必须先获得独占锁。
-当第二个事务也要访问相同的资源时，如果执行select语句，也必须获得共享锁。
如果执行update、insert、delete语句，也必须先获得独占锁。
此时根据锁的类型。来决定第二个事务是应该等待第一个事务完成，还是可以立即获得锁。
许多数据库系统都有自动管理锁的功能，能够根据事务执行的sql语句，自动为资源加上适当的锁。
三、悲观锁和乐观锁
悲观锁 ：
指在应用程序显式的为数据资源加锁。悲观锁假定当前事务操纵数据资源时，一定会有其他事务同时访问资源。为了避免当前事务受到干扰，先锁定资源。悲观锁能够防止丢失更新和不可重复读等并发问题，但是会影响并发性能。需要谨慎使用。 悲观锁对事务处理很悲观，总是认为其他事务会占用资源。
当事务执行select语句时，默认使用共享锁来锁定查询的语句。也可以使用 select ..... lock in share mode来指定使用共享锁。
使用select .... for update来指定采用独占锁来锁定查询的记录
例如取款：select * from bank where id=1 for update
那么这条记录就被锁定，其他事务如果要处理这条数据，必须停下来等待。直到我们的取款事务结束。
Hibernate应用中，当通过Session的get()和load()方法来加载一个对象时，可以采用以下方式使用悲观锁。
Session.get(Clsss,OID,锁的类型);
锁的类型
LockMode.UPGRADE:使用悲观锁，也就是独占锁。
乐观锁 ：
乐观锁假定当前事务操纵数据资源时，不会有其他事务同时访问该数据资源。 因此完全由数据库的隔离级别来控制，或者我们自己来实现。乐观锁对事务的态度总是很乐观。
实现的原理
在数据表中添加Version字段，初始化为0，事务提交的前提是我的数据Version字段必须比数据库中的Version字段小1。
例如同时两个付款单，A付款事务的时候会先取出金额，然后付款，修改余额，然后将version字段加一
B付款事务执行同样的操作，然后事务提交。
如果A先提交事务，version变为1.B再提交的时候version也变为1，然后就会发现Version的值是一样的，这时就会抛出异常
Hibernate帮我们实现了这种操作。
我们需要在我们的实体类中添加一个version属性，并添加get/set方法。
然后在实体类的映射文件中配置这个属性，紧跟在<id>元素后面有一个version元素，name值为version属性名。
<version name="version"></version>