数据库事务
锁详解：http://blog.csdn.net/xifeijian/article/details/20313977
http://www.cnblogs.com/zhangpengme/archive/2011/11/24/2261625.html
http://www.cnblogs.com/zhangpengme/archive/2011/11/24/2261975.html
http://www.cnblogs.com/zhangpengme/archive/2011/11/26/2264484.html
http://www.cnblogs.com/kristain/articles/2038397.html
http://www.2cto.com/database/201301/185438.html
http://book.51cto.com/art/201007/213844.htm
概述
数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作。 事务处理可以确保事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID(原子性、一致性、隔离性和持久性)属性。
数据库事务的ACID属性
原子性（atomic）
事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。
一致性（consistent）
事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。简单来说，事务的执行使得数据库从一种正确状态转换成另一种正确状态。
理解： http://www.2cto.com/database/201301/185438.html
（原子性： 意思是各种操作集合是一个最好原子单位，如批处理update语句。 一致性 ： 则趋向于是业务逻辑上的，如添加了员工记录，却没有添加员工职位；或者是数据库隔离机制来保证的数据库并发处理的安全性）
隔离性（insulation）
由并发事务所作的修改必须与任何其它并发事务所作的修改隔离(即事务并发处理的隔离机制问题，多用户之间相互不干扰)。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。由于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。防止数据丢失
持久性(durability）
事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持。
数据并发的问题
http://www.cnblogs.com/zhangpengme/archive/2011/11/24/2261975.html
- 第一类丢失更新：撤销一个事务时，把其他事务已提交的更新数据覆盖。
- 脏读：一个事务读到另一个事务未提交的更新数据。
- 虚读：一个事务读到另一个事务已提交的新插入的数据。
- 不可重复读：一个事务读到另一个事务已提交的更新数据。
- 第二类丢失更新：这是不可重复读中的特例，一个事务覆盖另一个事务已提交的更新数据
事务隔离级别
|
隔离级别
|
脏读
|
不可
重复读
|
幻象读
|
第一类丢失更新
|
第二类丢失更新
|
|
READ UNCOMMITED
|
允许
|
允许
|
允许
|
不允许
|
允许
|
|
READ COMMITTED
|
不允许
|
允许
|
允许
|
不允许
|
允许
|
|
REPEATABLE READ
|
不允许
|
不允许
|
允许
|
不允许
|
不允许
|
|
SERIALIZABLE
|
不允许
|
不允许
|
不允许
|
不允许
|
不允许
|
- Serializable(串行化)：一个事务在执行过程中完全看不到其他事务对数据库所做的更新。
- Repeatable Read(可重复读)：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，但是不能看到其他事务对已有记录的更新。
- Read Commited（读已提交数据）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，而且能看到其他事务已经提交的对已有记录的更新
- Read Uncomitted（读未提交数据）：一个事务在执行过程中可以看到其他事务没有提交的新插入的记录，而且能看到其他事务没有提交的对已有记录的更新
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以有优先考虑把数据库系统的隔离级别设为Read Commited，它能够避免脏读，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
当数据库系统采用read Commited隔离级别时，会导致不可重复读喝第二类丢失更新的并发问题，可以在应用程序中采用悲观锁或乐观锁来避免这类问题。从应用程序的角度，锁可以分为以下几类：
A.悲观锁：指在应用程序中显示的为数据资源加锁。尽管能防止丢失更新和不可重复读这类并发问题，但是它会影响并发性能，因此应该谨慎地使用。
B.乐观锁：乐观锁假定当前事务操作数据资源时，不回有其他事务同时访问该数据资源，因此完全依靠数据库的隔离级别来自动管理锁的工作。应用程序采用版本控制手段来避免可能出现的并发问题。
乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据
五、悲观锁有两种实现方式。
A.在应用程序中显示指定采用数据库系统的独占所来锁定数据资源。SQL语句：select ... for update，在Hibernate中使用get，load时如session.get(Account.class,new Long(1),LockMode,UPGRADE)
B.在数据库表中增加一个表明记录状态的LOCK字段，当它取值为“Y”时，表示该记录已经被某个事务锁定，如果为“N”，表明该记录处于空闲状态，事务可以访问它。增加锁标记字段就可以实现。
利用Hibernate的版本控制来实现乐观锁
乐观锁是由程序提供的一种机制，这种机制既能保证多个事务并发访问数据，又能防止第二类丢失更新问题。
在应用程序中可以利用Hibernate提供的版本控制功能来视线乐观锁，OR映射文件中的<version>元素和<timestamp>都具有版本控制的功能，一般推荐采用<version>
详细锁机制，及SQL写法：
http://www.cnblogs.com/haiyang1985/archive/2009/02/27/1399641.html
