1.0 事务特性(ACID)
Atomicity：原子性，一个事务不可以被拆分
Consistency：一致性，在事务执行前数据库的数据处于正确的状态，而事务执行完成后数据库的数据还是处于正确的状态，即数据完整性约束没有被破坏；比如我们做银行转账的相关业务，A转账给B，要求A转的钱B一定要收到。如果A转了钱而B没有收到，那么数据库数据的一致性就得不到保障，在做高并发业务时要注意合理的设计。
Isolation：隔离性，并发事务执行之间无影响，在一个事务内部的操作对其他事务是不产生影响，这需要事务隔离级别来指定隔离性；
Durability：持久性，事务一旦执行成功，它对数据库的数据的改变必须是永久的，不会因各种异常导致数据不一致或丢失。
1.1 事务的隔离级别
READ_UNCOMMITTED 会出现脏读、不可重复读、幻读 ( 隔离级别最低，并发性能高 )
READ_COMMITTED 会出现不可重复读、幻读问题（锁定正在读取的行）
REPEATABLE_READ 会出幻读（锁定所读取的所有行）
SERIALIZABLE 保证所有的情况不会发生（锁表）
|
大多数数据库的默认隔离级别为: Read Commited,如Sql Server , Oracle. |
1.2事务并发引起的问题
1.2.1脏读：数据已修改事务没提交，另一事务读取到未提交的数据！（事务没提交另一事务就读到未提交的数据）
1.2.2不可重复读：同一事务两次读取数据不一样；第一个事务读去数据，第二个事务修改数据提交，第一个事务再一次读取数据，这样第一个事务两次读取的数据将不一致。
1.2.3幻读：两个事务，第一个事务将所有行的数据都修改了，第二个事务将插入一条数据提交，第1个事务提交发现有一条数据并没有修改。
1.2.4第一类丢失（回滚丢失）：
当2个事务更新相同的数据源，如果第一个事务被提交，而另外一个事务却被撤销，那么会连同第一个事务所做的跟新也被撤销。也就是说第一个事务做的跟新丢失了
1.2.5第二类更新丢失(覆盖丢失)
加深理解：
- 不可重复读和幻读的区别
两者都是相同事务两次读取不一致，一个是被另外事务修改读取不一致，一个是被另外事务插入/删除读取不一致。
2.spring事务
引用文章：http://blog.csdn.net/it_man/article/details/5074371
2.1 事务传播行为（Transaction Propagation Behavior）
事务在方法中传播。
- PROPAGATION_REQUIRED
- RROPAGATION_REQUIRES_NEW
- PROPAGATION_NESTED
- PROPAGATION_SUPPORTS
- PROPAGATION_NOT_SUPPORTED
- PROPAGATION_NEVER
- PROPAGATION_MANDATORY
首先要明确的是，事务是从哪里来？传播到哪里去？答案是，从方法 A 传播到方法 B。Spring 解决的只是方法之间的事务传播，那情况就多了，比如：
- 方法 A 有事务，方法 B 也有事务。
- 方法 A 有事务，方法 B 没有事务。
- 方法 A 没有事务，方法 B 有事务。
- 方法 A 没有事务，方法 B 也没有事务。
- B没有事务 A有事务 B调用A 整个是没有事务的 再声明式事务aop切入过来以后 已经B 没有事务了 事务的传递性 A也没有事务
假设事务从方法 A 传播到方法 B，您需要面对方法 B，问自己一个问题：
方法 A 有事务吗？
- 如果没有，就新建一个事务；如果有，就加入当前事务。这就是 PROPAGATION_REQUIRED，它也是 Spring 提供的默认事务传播行为，适合绝大多数情况。
- 如果没有，就新建一个事务；如果有，就将当前事务挂起。这就是 RROPAGATION_REQUIRES_NEW，意思就是创建了一个新事务，它和原来的事务没有任何关系了。
- 如果没有，就新建一个事务；如果有，就在当前事务中嵌套其他事务。这就是 PROPAGATION_NESTED，也就是传说中的“嵌套事务”了，所嵌套的子事务与主事务之间是有关联的（当主事务提交或回滚，子事务也会提交或回滚）。
- 如果没有，就以非事务方式执行；如果有，就使用当前事务。这就是 PROPAGATION_SUPPORTS，这种方式非常随意，没有就没有，有就有，有点无所谓的态度，反正我是支持你的。
- 如果没有，就以非事务方式执行；如果有，就将当前事务挂起。这就是 PROPAGATION_NOT_SUPPORTED，这种方式非常强硬，没有就没有，有我也不支持你，把你挂起来，不鸟你。
- 如果没有，就以非事务方式执行；如果有，就抛出异常。这就是 PROPAGATION_NEVER，这种方式更猛，没有就没有，有了反而报错，确实够牛的，它说：我从不支持事务！
- 如果没有，就抛出异常；如果有，就使用当前事务。这就是 PROPAGATION_MANDATORY，这种方式可以说是牛逼中的牛逼了，没有事务直接就报错，确实够狠的，它说：我必须要有事务！
2.2 spring 事务隔离级别
DEFAULT 使用数据库设置的隔离级别 ( 默认 ) ，由 DBA 默认的设置来决定隔离级别 .
READ_UNCOMMITTED 会出现脏读、不可重复读、幻读 ( 隔离级别最低，并发性能高 )
READ_COMMITTED 会出现不可重复读、幻读问题（锁定正在读取的行）
REPEATABLE_READ 会出幻读（锁定所读取的所有行）
SERIALIZABLE 保证所有的情况不会发生（锁表）
不可重复读的重点是修改 :
同样的条件 , 你读取过的数据 , 再次读取出来发现值不一样了
幻读的重点在于新增或者删除
同样的条件 , 第 1 次和第 2 次读出来的记录数不一样
|
1、Serializable：最严格的级别，事务串行执行，资源消耗最大； 2、REPEATABLE READ：保证了一个事务不会修改已经由另一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的情况，但是带来了更多的性能损失。 3、READ COMMITTED:大多数主流数据库的默认事务等级，保证了一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。 4、Read Uncommitted：保证了读取过程中不会读取到非法数据。隔离级别在于处理多事务的并发问题。 |
2.3 spring 事务管理的方式
声明式事务：TransactionProxyFactoryBean 在spring 配置文件中进行配置或者使用注解
编程式事务：TransactionTemplate PlatformTransactionManager
3 .数据库锁
- 悲观锁：利用数据库本身的锁机制实现。通过上面对数据库锁的了解，可以根据具体业务情况综合使用事务隔离级别与合理的手工指定锁的方式比如降低锁的粒度等减少并发等待。
- 乐观锁：利用程序处理并发。原理都比较好理解，基本一看即懂。方式大概有以下3种
- 对记录加版本号.
- 对记录加时间戳.
- 对将要更新的数据进行提前读取、事后对比。
不论是数据库系统本身的锁机制，还是乐观锁这种业务数据级别上的锁机制，本质上都是对状态位的读、写、判断。
http://www.cnblogs.com/zhouqianhua/archive/2011/04/15/2017049.html
参考文章:
http://www.codeweblog.com/%E4%BA%8B%E5%8A%A1-%E9%94%81-spring%E6%94%AF%E6%8C%81/
http://blog.csdn.net/it_man/article/details/5074371
http://www.cnblogs.com/zhouqianhua/archive/2011/04/15/2017049.html
http://www.cnblogs.com/yldIndex/p/spring_Transactional.html
http://blog.csdn.net/yangchangyong0/article/details/51996708