谈谈个人对底层事物的理解

一。事物的基本理解
一个Java应用系统，如果要操作数据库，则通过JDBC来实现的。增加、修改、删除都是通过相应方法间接来实现的，事务的控制也相应转移到Java程序代码中。
因此，数据库操作的事务习惯上就称为Java事务。

事务是为解决数据安全操作提出的，事务控制实际上就是控制数据的安全访问。
举一个简单例子：比如银行转帐业务，账户A要将自己账户上的1000元转到B账 户下面，A账户余额首先要减去1000元，然后B账户要增加1000元。假如在中间网络出现了问题，
A账户减去1000元已经结束，B因为网络中断而操作 失败，那么整个业务失败，必须做出控制，要求A账户转帐业务撤销。这才能保证业务的正确性，
完成这个操作就需要事务，将A账户资金减少和B账户资金增加方 到一个事务里面，要么全部执行成功，要么操作全部撤销，这样就保持了数据的安全性。

Spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。对于纯JDBC操作数据库，想要用到事务，可以按照以下步骤进行：
1、获取连接 Connection con = DriverManager.getConnection()
2、开启事务con.setAutoCommit(true/false);
3、执行CRUD
4、提交事务/回滚事务 con.commit() / con.rollback();
5、关闭连接 conn.close();
使用Spring的事务管理功能后，我们可以不再写步骤 2 和 4 的代码，而是由Spirng 自动完成。那么Spring是如何在我们书写的 CRUD 之前和之后开启事务和关闭事务的呢？解决这个问题，也就可以从整体上理解Spring的事务管理实现原理了。下面简单地介绍下，注解方式为例子
1、配置文件开启注解驱动，在相关的类和方法上通过注解@Transactional标识。
2、spring 在启动的时候会去解析生成相关的bean，这时候会查看拥有相关注解的类和方法，并且为这些类和方法生成代理，并根据@Transaction的相关参数进行相关配置注入，这样就在代理中为我们把相关的事务处理掉了（开启正常提交事务，异常回滚事务）。
3、真正的数据库层的事务提交和回滚是通过binlog或者redo log实现的。

另外， @Transactional 注解应该只被应用到 public 方法上，这是由 Spring AOP 的本质决定的。如果你在 protected、private 或者默认可见性的方法上使用 @Transactional 注解，这将被忽略，也不会抛出任何异常。

二。Java事务的类型有三种：JDBC事务、JTA(Java Transaction API)事务、容器事务。这是从事务的实现角度区分的，本文从另外一个角度来再次区分一下Java中的事务。
站在事务管理的角度，可以把Java中用到的事务分为本地事务和全局事务。
本地事务：
不用事务的编程框架来管理事务，直接使用资源管理器来控制事务。典型的就是java.sql.Connection 中的 setAutoCommit、commit、rollback方法。
本地事务的优点：支持严格的ACID属性，可靠，高效，状态可以只在资源管理器中维护，应用编程模型简单。
本地事务的局限：不具备分布式事务处理能力，隔离的最小单位由资源管理器决定，如数据库中的一条记录，本地事务比较简单，

全局事务：全局事务就是一个标准的分布式事务，是由资源管理器管理和协调的事务。
前面我们介绍了本地事务，本地事务是我们在编程中比较常接触的事务，比如典型的jdbc操作，在保证ACID方面做的非常出色。但是本地事务无法解决分布式场景中的事务问题。
典型的分布式事务场景：
转账：对于银行账户间转账的问题。账户A向账户B转账，从实现上来看，一般可以拆分为“从账户A中扣钱”、“向账户B中加钱”两个操作步骤，两个账户大多数情况下会被切分到不同的数据库上，更多的是，两个操作会是两次服务调用。这两个操作要求做到要么同时成功、要么同时失败。因此引入了分布式事务问题。
下单：在电商网站上，在消费者点击购买按钮后，交易后台会进行库存检查、下单、减库存、更新订单状态等一连串的服务调用，每一个操作对应一个独立的服务，服务一般会有独立的数据库，因此会产生分布式事务问题。
由于用一次操作，数据要写入的数据库不一致，或者调用的服务都是RPC服务，那么就会无法保证操作在同一个事务中被处理掉。所以就会存在分布式的事务问题

三。事务属性
事务属性描述了事务策略如何应用到方法上事务属性包含5个方面：传播行为，隔离级别，回滚规则，事务超时，是否只读
传播行为：传播行为定义了客户端与被调用方法之间的事务边界，即传播规则回答了这样的一个问题，新的事务应该被启动还是挂起，或者方法是否要在事务环境中运行。

隔离级别：隔离级别定义了一个事务可能受其他并发事务影响的程度。多事务并发可能会导致脏读、幻读、不可重复读等各种读现象
ISOLATION_DEFAULT:使用后端数据库默认的规则
ISOLATION_READ_UNCOMMITTED:允许读取尚未提交的数据变更，可能会导致脏读，幻读或不可重复读
ISOLATION_READ_COMMITTED:允许读取并发事务已经提交的数据，可以防止脏读，但是幻读或不可重复读仍有可能发生
ISOLATION_REPEATABLE_READ:对同意字段的多次读取结果是一致的，除非数据是被本事务自己所修改，看阻止脏读和不可重复读，但幻读仍有可能发生
ISOLATIOM_SERIALIZABLE:完全服从ACID的隔离级别，确保阻止脏读，不可重复读以及幻读，这是最慢的数据隔离级别

回滚规则：事务回滚规则定义了哪些异常会导致事务回滚而哪些不会。默认情况下，（重）事务只有在遇到运行时期异常才回滚，而在遇到检查型异常时不会回滚。

事务超时：为了使应用程序很好地运行，事务不能运行太长时间。因为超时时钟会在事务开始时启动，所以只有对那些具备可能启动一个新事务的传播行为（PROPAGATION_REQUIRED,PROPAGATION_REQUIRED_NEW,PROPAGATION_NESTED）的方法来说，才有意义。

是否只读：如果事务只对后端的数据库进行读操作，数据库可以利用事务ID只读特性来进行一些特定的优化。通过将事务设置为只读，你就可以给数据库一个机会，让他应用它认为合适的优化措施。因为是否只读是在事务启动的时候由数据库实施的，所以只有对那些具备可能启动一个新事务的传播行为（PROPAGATION_REQUIRED,PROPAGATION_REQUIRED_NEW,PROPAGATION_NESTED）的方法来说，才有意义。

四。事物配置方式
事务属性的配置方式通过以下关键字来指定：
关键字    含义
isolation    指定事务的隔离级别
propagation    定义事务的传播规则
read-only    指定事务为只读
rollback-for
no-rollback-for    rollback-for指定事务对哪些检查型异常应当回滚而不提交
no-rollback-for指定事务对哪些异常应当继续执行而不回滚
timeout    对于长时间运行的事务定义超时时间
XML中AOP事务属性的配置方式如下：
<!-- 2.基于xml配置的声明事务范围及类型  定义通知， 通知中要处理的就是事务 -->
 

<tx:advice id="txAdvice" transaction-manager="txManager">
    <tx:attributes>
        <!-- 配置具体方法事务属性
            isolation:事务隔离级别，默认为数据库隔离级别   
            propagation:事务传播行为：默认是同一事务
            timeout="-1":事务超时时间，默认值使用数据库的超时时间
            read-only="false":事务是否只读，默认是可读写
            rollback-for:遇到那些异常就回滚，其他都不回滚
            no-rollback-for:遇到那些异常不会滚， 其他都回滚        
         -->
        <tx:method name="save"  propagation="REQUIRED" isolation="DEFAULT" 
            read-only="false" rollback-for="java.lang.NullPointException"/>
        <!-- 支持通配符 -->
        <tx:method name="find*" read-only="true"/>
        <tx:method name="add*"/>
        <tx:method name="update*"/>
        <tx:method name="delete*"/>
    </tx:attributes>
  </tx:advice>

注解中事务属性的配置方式如下：

@Transaction(propagation=Propagation. REQUIRED,readOnly=true)
public void add(String username){
    //...
}

五。Spring @Transactional工作原理，待续