事务首先是一系列操作组成的工作单元，该工作单元内的操作是不可分割的，即要么所有操作都做，要么所有操作都不做

ACID

1.原子性（Atomicity）
    即事务是不可分割的最小工作单元，事务内的操作要么全做，要么全不做
2.一致性（Consistency）
    在事务执行前数据库的数据处于正确的状态，而事务执行完成后数据库的数据还是处于正确的状态，即数据完整性约束没有被破坏
    如银行转帐，A转帐给B，必须保证A的钱一定转给B，一定不会出现A的钱转了但B没收到，否则数据库的数据就处于不一致（不正确）的状态
3.隔离性（Isolation）
    并发事务执行之间无影响，在一个事务内部的操作对其他事务是不产生影响，这需要事务隔离级别来指定隔离性
4.持久性（Durability）
    事务一旦执行成功，它对数据库的数据的改变必须是永久的，不会因比如遇到系统故障或断电造成数据不一致或丢失

常见问题

1.丢失更新
    两个事务同时更新一行数据，最后一个事务的更新会覆盖掉第一个事务的更新，从而导致第一个事务更新的数据丢失，这是由于没有加锁造成的
2.脏读
    一个事务看到了另一个事务未提交的更新数据
3.不可重复读
    在同一事务中，多次读取同一数据却返回不同的结果；也就是有其他事务更改了这些数据
    不可重复读的重点是修改
4.幻读
    一个事务在执行过程中读取到了另一个事务已提交的插入数据；即在第一个事务开始时读取到一批数据，但此后另一个事务又插入了新数据并提交，此时第一个事务又读取这批数据但发现多了一条，即好像发生幻觉一样
    幻读的重点在于新增或者删除

隔离级别

1.未提交读（Read Uncommitted）
    最低隔离级别，一个事务能读取到别的事务未提交的更新数据，很不安全，可能出现丢失更新、脏读、不可重复读、幻读
2.提交读（Read Committed）
    一个事务能读取到别的事务提交的更新数据，不能看到未提交的更新数据，不可能可能出现丢失更新、脏读，但可能出现不可重复读、幻读
3.可重复读（Repeatable Read）
    保证同一事务中先后执行的多次查询将返回同一结果，不受其他事务影响，可能出现丢失更新、脏读、不可重复读，但可能出现幻读
4.序列化（Serializable）
    最高隔离级别，不允许事务并发执行，而必须串行化执行，最安全，不可能出现更新、脏读、不可重复读、幻读

    隔离级别越高，数据库事务并发执行性能越差，能处理的操作越少。因此在实际项目开发中为了考虑并发性能一般使用提交读隔离级别，它能避免丢失更新和脏读，尽管不可重复读和幻读不能避免，但可以在可能出现的场合使用悲观锁或乐观锁来解决这些问题
从数据库系统的角度来看，锁分为以下三种类型
1.独占锁（Exclusive Lock）
    独占锁锁定的资源只允许进行锁定操作的程序使用，其它任何对它的操作均不会被接受。执行数据更新命令，即INSERT、 UPDATE 或DELETE 命令时，SQL Server 会自动使用独占锁。但当对象上有其它锁存在时，无法对其加独占锁。独占锁一直到事务结束才能被释放
2.共享锁（Shared Lock）
    共享锁锁定的资源可以被其它用户读取，但其它用户不能修改它。在SELECT 命令执行时，SQL Server 通常会对对象进行共享锁锁定。通常加共享锁的数据页被读取完毕后，共享锁就会立即被释放
3.更新锁（Update Lock）
    更新锁是为了防止死锁而设立的。当SQL Server 准备更新数据时，它首先对数据对象作更新锁锁定，这样数据将不能被修改，但可以读取。等到SQL Server 确定要进行更新数据操作时，它会自动将更新锁换为独占锁。但当对象上有其它锁存在时，无法对其作更新锁锁定

从程序员的角度看，锁分为以下两种类型
1.悲观锁（Pessimistic Lock）
    悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）
2.乐观锁（Optimistic Lock）
    相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受
    而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如 果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据

数据库事务类型
本地事务
    就是普通事务，能保证单台数据库上的操作的ACID，被限定在一台数据库上
分布式事务
    涉及两个或多个数据库源的事务，即跨越多台同类或异类数据库的事务（由每台数据库的本地事务组成的），分布式事务旨在保证这些本地事务的所有操作的ACID，使事务可以跨越多台数据库

Java事务类型
    JDBC事务：就是数据库事务类型中的本地事务，通过Connection对象的控制来管理事务
    JTA事务：JTA指Java事务API(Java Transaction API)，是Java EE数据库事务规范， JTA只提供了事务管理接口，由应用程序服务器厂商（如WebSphere Application Server）提供实现，JTA事务比JDBC更强大，支持分布式事务

Java EE事务类型
    本地事务：使用JDBC编程实现事务
    全局事务：由应用程序服务器提供，使用JTA事务

编程实现
    声明式事务： 通过注解或XML配置文件指定事务信息
    编程式事务：通过编写代码实现事务

Spring事务使用
说明
结构
    DataSource
        JdbcDataSource
        SessionFactory
        EntityManager
    TransactionManager
        DataSourceTransactionManager
        HibernateTransactionManager
        JpaTransactionManager
    代理机制
        Bean和代理
            每个Bean有一个代理
            所有Bean共享一个代理基类
        使用拦截器
        使用TX标签配置的拦截器
        全注解配置
无论哪种配置方式，一般变化的只是代理机制这部分

5种实现方式

1.每个Bean都有一个代理
    每个Bean用TransactionProxyFactoryBean代理
2.所有Bean共享一个代理基类
    所有Bean都集成TransactionProxyFactoryBean
3.使用拦截器
    拦截器：TransactionInterceptor
    根据beanName匹配后进行自动代理: BeanNameAutoProxyCreator
4.使用tx标签配置的拦截器
    <tx:advice/>
    <aop:config/>
5.全注解
    Transactional

更多内容请关注微信公众号：IT哈哈（it_haha）

本文出自 “doujh” 博客，请务必保留此出处http://doujh.blog.51cto.com/10177066/1932115

Spring事务