Java的事务学习与扩展

1.Java事务

Java事务的类型有三种：JDBC事务、JTA（Java Transaction API）事务、容器事务。

JDBC事务

JDBC 事务是用 Connection 对象控制的。JDBC Connection 接口（ java.sql.Connection ）提供了两种事务模式：自动提交和手工提交。

java.sql.Connection 提供了以下控制事务的方法：
public void setAutoCommit(boolean) //设置java事务是否自动提交，true为自动提交，false则需要手动commit或rollback
public boolean getAutoCommit()//获取当前java事务的提交状态
public void commit()//提交事务
public void rollback()//回滚事务

注：事务周期限于Connection的生命周期。JDBC 事务的一个缺点是事务的范围局限于一个数据库连接。一个 JDBC 事务不能跨越多个数据库。

具体使用：

//JDBC事务
public static void main(String[] args) throws SQLException, ClassNotFoundException {
    
    
        Class.forName("com.mysql.jdbc.Driver");
        String url = "jdbc:mysql://localhost:3306/user";
        String user = "root";
        String password = "123456";
        Connection con = (Connection) DriverManager.getConnection(url, user, password);
        try {
    
    
            //取消自动提交
            //如果设成false,那就是JDBC不自动提交，需要手动的使用commit或者rollback来进行提交或者回滚数据.
            con.setAutoCommit(false);
            Statement stmt = (Statement) con.createStatement();
            //进行数据插入
            String sql = "insert into users(email,password) values('" + "[email protected]" + "','" + "jack" + "');";
            boolean flag = stmt.execute(sql);
            System.out.println(flag);
            //人为制造一个错误，结果就是数据库并没有插入这条数据，也就是数据发生了回滚
            //异常被捕获之后，就不在执行下面的语句，而是执行catch中的语句
            //如果没有异常，数据就会被提交到数据库
            System.out.println(1/0);
            //手动提交
            con.commit();
        } catch (Exception e) {
    
    
            //如果发生错误，就回滚
            con.rollback();
        } finally {
    
    
            con.close();
        }
    }

public int delete(int sID) {
    
    
　 dbc = new DataBaseConnection();
　 Connection con = dbc.getConnection();
　 try {
    
    
　　 con.setAutoCommit(false);// 更改JDBC事务的默认提交方式
　　 dbc.executeUpdate("delete from xiao where ID=" + sID);
　　 dbc.executeUpdate("delete from xiao_content where ID=" + sID);
　　 dbc.executeUpdate("delete from xiao_affix where bylawid=" + sID);
　　 con.commit();//提交JDBC事务
　　 con.setAutoCommit(true);// 恢复JDBC事务的默认提交方式
　　 dbc.close();
　　 return 1;
　 }
　 catch (Exception exc) {
    
    
　　 con.rollBack();//回滚JDBC事务
　　 exc.printStackTrace();
　　 dbc.close();
　　 return -1;
　 }
}

JDBC事务隔离级别：

JDBC定义了五种事务隔离级别：

TRANSACTION_NONE 说明不支持事务。

TRANSACTION_READ_UNCOMMITTED 说明在提交前一个事务可以看到另一个事务的变化。这样脏读、不可重复的读和虚读都是允许的。

脏读：在没有提交数据时能够读到已经更新的数据

TRANSACTION_READ_COMMITTED 说明读取未提交的数据是不允许的。这个级别仍然允许不可重复的读和虚读产生。

不可重复的读：在一个事务中进行查询时，允许读取提交前的数据，数据提交后，当前查询就可以读取到数据。update数据时候并不锁住表

TRANSACTION_REPEATABLE_READ 说明事务保证能够再次读取相同的数据而不会失败，但虚读仍然会出现。

虚读：允许读取到其他事务提交的新增数据

TRANSACTION_SERIALIZABLE 是最高的事务级别，它防止脏读、不可重复的读和虚读，在一个事务中进行查询时，不允许任何对这个查询表的数据修改。

在JDBC中，通过如下API设置事务隔离级别

conn.setTransactionLevel(TRANSACTION_SERIALIZABLE) ;``int` `level = conn.getTransactionIsolation();

保存点(SavePoint)：

JDBC定义了SavePoint接口，提供了一个更细粒度的事务控制机制。当设置了一个保存点后，可以rollback到该保存点处的状态，而不是rollback整个事务。

Connection接口的setSavepoint和releaseSavepoint方法可以设置和释放保存点。

Savepoint sp = conn.setSavepoint();``Conn.rollback(sp);``Conn.commit();  ``//回滚后必须要提交

JDBC规范虽然定义了事务的以上支持行为，但是各个JDBC驱动，数据库厂商对事务的支持程度可能各不相同。如果在程序中任意设置，可能得不到想要的效果。

JDBC优缺点：

1.冗长、重复
2.显示事务控制
3.每个步骤不可获取
4.显示处理受检查异常

JDBC为使用Java进行数据库的事务操作提供了最基本的支持。通过JDBC事务，我们可以将多个SQL语句放到同一个事务中，保证其ACID特性。JDBC事务的主要优点就是API比较简单，可以实现最基本的事务操作，性能也相对较好。但是，JDBC事务有一个局限：一个 JDBC 事务不能跨越多个数据库！所以，如果涉及到多数据库的操作或者分布式场景，JDBC事务就无能为力了。

2.JTA事务（初学者了解即可）

JTA全称Java Transaction API ，即Java事务API，英文解释：

Java Transaction API (JTA) specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications.

JTA是一种高层的，与实现无关的，与协议无关的API，应用程序和应用服务器可以使用JTA来访问事务。

JTA允许应用程序执行分布式事务处理–在两个或多个网络计算机资源上访问并且更新数据，这些数据可以分布在多个数据库上。JDBC驱动程序的JTA支持极大地增强了数据访问能力。

JTA的主要接口：

位于javax.transaction包中

a、UserTransaction接口：让应用程序得以控制事务的开始、挂起、提交、回滚等。由Java客户端程序或EJB调用。
b、TransactionManager 接口：用于应用服务器管理事务状态
c、Transaction接口：用于执行相关事务操作
d、XAResource接口：用于在分布式事务环境下，协调事务管理器和资源管理器的工作
e、Xid接口：为事务标识符的Java映射

注：前3个接口位于Java EE版的类库 javaee.jar 中，Java SE中没有提供！UserTransaction是编程常用的接口。JTA只提供了接口，没有具体的实现。

JTA需要满足的条件：

如果使用 JTA 界定事务，那么就需要有一个实现 javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC 驱动程序。一个实现了这些接口的驱动程序才可以参与 JTA 事务。

一个 XADataSource 对象就是一个 XAConnection 对象的工厂。 XAConnection 是参与 JTA 事务的 JDBC 连接。要使用JTA事务，必须使用XADataSource来产生数据库连接，产生的连接为一个XA连接。

XA连接（javax.sql.XAConnection）和非XA（java.sql.Connection）连接的区别在于：

XA可以参与JTA的事务，而且不支持像JDBC那样的自动提交。

同时，应用程序一定不要对 XA 连接调用 java.sql.Connection.commit() 或者 java.sql.Connection.rollback() 。相反，应用程序应该使用 UserTransaction.begin()、 UserTransaction.commit() 和 serTransaction.rollback() 。

注意： Oracle, Sybase, DB2, SQL Server等大型数据库才支持XA, 支持分布事务。 MySQL属于Non-XA。

事务管理器模型（TM）：

Java Transaction API 允许您操作应用程序中的分布式事务（Distributed Transaction）。JTA 中有一组方法，它将传统的 JDBC 调用封装到了两阶段提交（Two-Phase-Commit）协议中。

在异构环境中，您通常会发现一个事务管理器（Transaction Manager），负责处理分布式事务。（实际上，事务管理器可以完成大量的工作负载平衡。）因此，不仅存在到数据库的直接连接，还有到事务管理器（Transaction Manager）的连接。这就是 JTA 发挥作用的地方：JTA 是 Java 应用程序和事务管理器（Transaction Manager）之间的接口。下图演示了一个包含分布式事务的典型环境。

由于存在事务管理器（Transaction Manager），它通常包含在应用程序服务器（Application Server）中，就不再有两层（Two-Tier）架构。传统的客户/服务器（Client/Server）架构已经由三层（Tree-Tier）架构所取代，三层架构包含****应用程序/客户机、事务管理器（Transaction Manager）/应用程序服务器（Application Server）和数据库服务器，而数据库服务器一般称作XA Resource。

在这里插入图片描述

包含 SQL 和 JTA 调用的 Java 应用程序。
管理分布式事务的应用程序服务器（Application Server）。
参与分布式事务的数据库。
Java 应用程序向应用程序服务器（Application Server）提交常规 SQL 语句和通用的 XA 调用。
应用程序所发送的消息由应用程序服务器（Application Server）进行处理，并使用 SQL 和数据库供应商特定的 XA 调用发送给数据库。

通常，应用程序服务器（Application Server）提供了应用程序可以使用的多种服务。在谈到分布式事务时，该服务就称作XA Resource。当然，在应用程序可以使用 XA Resource 之前，首先要在应用程序服务器中注册和配置 XA Resource。

现在，如果您计划在应用程序中使用 JTA，就必须修改代码，以便还可以与应用程序服务器（Application Server）进行通信。这包括一些附加的方法调用和指定的错误/异常处理

分布式事务：

在谈到 XA 规范之前，必须首先了解分布式事务处理（ Distributed Transaction Processing ， DTP ）的概念。 Transaction ，即事务，又称之为交易，指一个程序或程序段，在一个或多个资源如数据库或文件上为完成某些功能的执行过程的集合。

分布式事务处理是指一个事务可能涉及多个数据库操作，分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。

分布式事务处理模型：

X/Open 组织（即现在的 Open Group ）定义了分布式事务处理模型。

**X/Open DTP 模型（ 1994 ）包括：**应用程序（ AP ）、事务管理器（ TM ）、资源管理器（ RM ）、通信资源管理器（ CRM ）四部分。一般，常见的事务管理器（ TM ）是交易中间件，常见的资源管理器（ RM ）是数据库，常见的通信资源管理器（ CRM ）是消息中间件。

通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。

所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处，但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。

一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。

XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数）。交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。XA 接口函数由数据库厂商提供。

XA协议包括两套函数，以xa_开头的及以ax_开头的。

以下的函数使事务管理器可以对资源管理器进行的操作：

1）xa_open,xa_close：建立和关闭与资源管理器的连接。

2）xa_start,xa_end：开始和结束一个本地事务。

3）xa_prepare,xa_commit,xa_rollback：预提交、提交和回滚一个本地事务。

4）xa_recover：回滚一个已进行预提交的事务。

5）ax_开头的函数使资源管理器可以动态地在事务管理器中进行注册，并可以对XID(TRANSACTION IDS)进行操作。

6）ax_reg,ax_unreg；允许一个资源管理器在一个TMS(TRANSACTION MANAGER SERVER)中动态注册或撤消注册。

JTA可以处理任何提供符合XA接口的资源。包括：JDBC连接，数据库，JMS，商业对象等等。

XA 与两阶段提交协议（Two-Phase-Commit）：

通常情况下，交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全局事务， XA 规范的基础是两阶段提交协议。

第一阶段：交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。

当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，此时数据库将不能再在该事务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态）。如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。

第二阶段：交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。

以一个全局事务为例， AP 首先通知交易中间件开始一个全局事务，交易中间件通过 XA 接口函数通知数据库开始事务，然后 AP 可以对数据库管理的资源进行操作，数据库系统记录事务对本地资源的所有操作。操作完成后交易中间件通过 XA 接口函数通知数据库操作完成。交易中间件负责记录 AP 操作过哪些数据库（事务分支）。 AP 根据情况通知交易中间件提交该全局事务，交易中间件会通过 XA 接口函数要求各个数据库做预提交，所有数据库返回成功后要求各个数据库做正式提交，此时一笔全局事务结束。

XA 规范对应用来说，最大好处在于事务的完整性由交易中间件和数据库通过 XA 接口控制， AP 只需要关注与数据库的应用逻辑的处理，而无需过多关心事务的完整性，应用设计开发会简化很多。

具体来说，如果没有交易中间件，应用系统需要在程序内部直接通知数据库开始、结束和提交事务，当出现异常情况时必须由专门的程序对数据库进行反向操作才能完成回滚。如果是有很多事务分支的全局事务，回滚时情况将变得异常复杂。而使用 XA 接口，则全局事务的提交是由交易中间件控制，应用程序只需通知交易中间件提交或回滚事务，就可以控制整个事务（可能涉及多个异地的数据库）的全部提交或回滚，应用程序完全不用考虑冲正逻辑。

在一个涉及多个数据库的全局事务中，为保证全局事务的完整性，由交易中间件控制数据库做两阶段提交是必要的。但典型的两阶段提交，对数据库来说事务从开始到结束（提交或回滚）时间相对较长，在事务处理期间数据库使用的资源（如逻辑日志、各种锁），直到事务结束时才会释放。因此，使用典型的两阶段提交相对来说会占用更多的资源，在网络条件不是很好，如低速网、网络颠簸频繁，情况会更为严重。

当一个全局事务只涉及一个数据库时，有一种优化方式，即一阶段提交。当 AP 通知交易中间件提交事务时，交易中间件直接要求数据库提交事务，省去两阶段提交中的第一阶段，可以缩短处理一个事务的时间，以提高事务处理的效率。作为两阶段提交的一种特例，与两阶段一样，一阶段提交也是标准的。

Two-phase commit

In an XA implementation, the transaction manager commits the distributed branches of a global transaction by using a two-phase commit protocol.

In phase one, the transaction manager directs each resource manager to prepare to commit, which is to verify and guarantee it can commit its respective branch of the global transaction. If a resource manager cannot commit its branch, the transaction manager rolls back the entire transaction in phase two.
In phase two, the transaction manager either directs each resource manager to commit its branch or, if a resource manager reported it was unable to commit in phase one, rolls back the global transaction.

Note the following optimizations:

If a global transaction is determined by the transaction manager to have involved only one branch, it skips phase one and commits the transaction in phase two.
If a global transaction branch is read-only, where it does not generate any transaction log records, the transaction manager commits the branch in phase one and skips phase two for that branch.

Note:

The transaction manager considers the global transaction committed if and only if all branches successfully commit.

两阶段提交详细说明：

在分布式系统中，事务往往包含有多个参与者的活动，单个参与者上的活动是能够保证原子性的，而多个参与者之间原子性的保证则需要通过两阶段提交来实现，两阶段提交是分布式事务实现的关键。

很明显，两阶段提交保证了分布式事务的原子性，这些子事务要么都做，要么都不做。而数据库的一致性是由数据库的完整性约束实现的，持久性则是通过 commit日志来实现的，不是由两阶段提交来保证的。至于两阶段提交如何保证隔离性，可以参考Large-scale Incremental Processing Using Distributed Transactions and Notifications中两阶段提交的具体实现。

两阶段提交的过程涉及到协调者和参与者。协调者可以看做成事务的发起者，同时也是事务的一个参与者。对于一个分布式事务来说，一个事务是涉及到多个参与者的。具体的两阶段提交的过程如下：

第一阶段：

首先，协调者在自身节点的日志中写入一条的日志记录，然后所有参与者发送消息prepare T，询问这些参与者（包括自身），是否能够提交这个事务；

参与者在接受到这个prepare T 消息以后，会根据自身的情况，进行事务的预处理，如果参与者能够提交该事务，则会将日志写入磁盘，并返回给协调者一个ready T信息，同时自身进入预提交状态状态；如果不能提交该事务，则记录日志，并返回一个not commit T信息给协调者，同时撤销在自身上所做的数据库改；

参与者能够推迟发送响应的时间，但最终还是需要发送的。

第二阶段：

协调者会收集所有参与者的意见，如果收到参与者发来的not commit T信息，则标识着该事务不能提交，协调者会将Abort T 记录到日志中，并向所有参与者发送一个Abort T 信息，让所有参与者撤销在自身上所有的预操作；

如果协调者收到所有参与者发来prepare T（ready T）信息，那么协调者会将Commit T日志写入磁盘，并向所有参与者发送一个Commit T信息，提交该事务。若协调者迟迟未收到某个参与者发来的信息，则认为该参与者发送了一个VOTE_ABORT信息，从而取消该事务的执行。

参与者接收到协调者发来的Abort T信息以后，参与者会终止提交，并将Abort T 记录到日志中；如果参与者收到的是Commit T信息，则会将事务进行提交，并写入记录。

一般情况下，两阶段提交机制都能较好的运行，当在事务进行过程中，有参与者宕机时，他重启以后，可以通过询问其他参与者或者协调者，从而知道这个事务到底提交了没有。当然，这一切的前提都是各个参与者在进行每一步操作时，都会事先写入日志。

唯一一个两阶段提交不能解决的困境是：当协调者在发出commit T消息后宕机了，而唯一收到这条命令的一个参与者也宕机了，这个时候这个事务就处于一个未知的状态，没有人知道这个事务到底是提交了还是未提交，从而需要数据库管理员的介入，防止数据库进入一个不一致的状态。当然，如果有一个前提是：所有节点或者网络的异常最终都会恢复，那么这个问题就不存在了，协调者和参与者最终会重启，其他节点也最终也会收到commit T的信息。

数据库日志保证了事务执行的原子性和持久性，日志类型可以分为redo log，undo log，undo/redo log。关于这几种日志形式的具体介绍，可以参照：http://nosql-wiki.org/foswiki/bin/view/Main/TransactonLog

3、Spring容器事务（初学者主要了解@Transactional注解）

Spring事务管理的实现有许多细节，如果对整个接口框架有个大体了解会非常有利于我们理解事务，下面通过讲解Spring的事务接口来了解Spring实现事务的具体策略。

Spring事务管理涉及的接口及其联系：

在这里插入图片描述

Spring并不直接管理事务，而是提供了多种事务管理器，他们将事务管理的职责委托给Hibernate或者JTA等持久化机制所提供的相关平台框架的事务来实现。 Spring事务管理器的接口是org.springframework.transaction.PlatformTransactionManager，通过这个接口，Spring为各个平台如JDBC、Hibernate等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。

Public interface PlatformTransactionManager{
    
      
       // 由TransactionDefinition得到TransactionStatus对象
       TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException;
    // 提交
       Void commit(TransactionStatus status) throws TransactionException;  
       // 回滚
       Void rollback(TransactionStatus status) throws TransactionException;  
}

基本的事务属性的定义:

事务管理器接口PlatformTransactionManager通过getTransaction(TransactionDefinition definition)方法来得到事务，这个方法里面的参数是TransactionDefinition类，这个类就定义了一些基本的事务属性。
事务属性可以理解成事务的一些基本配置，描述了事务策略如何应用到方法上。

事务属性包含了5个方面:

传播行为、隔离规则、回滚规则、事务超时、是否只读

TransactionDefinition：

public interface TransactionDefinition {
    
    
    int getPropagationBehavior(); // 返回事务的传播行为
    int getIsolationLevel(); // 返回事务的隔离级别，事务管理器根据它来控制另外一个事务可以看到本事务内的哪些数据
    int getTimeout();  // 返回事务必须在多少秒内完成
    boolean isReadOnly(); // 事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的
}

7种传播行为：

**PROPAGATION_REQUIRED：**如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
**PROPAGATION_SUPPORTS：**支持当前事务，如果当前没有事务，就以非事务方式执行。
**PROPAGATION_MANDATORY：**支持当前事务，如果当前没有事务，就抛出异常。
**PROPAGATION_REQUIRES_NEW：**新建事务，如果当前存在事务，把当前事务挂起。
**PROPAGATION_NOT_SUPPORTED：**以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
**PROPAGATION_NEVER：**以非事务方式执行，如果当前存在事务，则抛出异常。

虽然有7种，但是常用的就第一种REQUIRED和第四种REQUIRES_NEW

五个隔离级别：

**ISOLATION_DEFAULT：**这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应；
**ISOLATION_READ_UNCOMMITTED：**这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。
**ISOLATION_READ_COMMITTED：**保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。
**ISOLATION_REPEATABLE_READ：**这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
**ISOLATION_SERIALIZABLE：**这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。

除了防止脏读，不可重复读外，还避免了幻像读。

事务的属性可同通过注解方式或配置文件配置:

注解方式：@Transactional

步骤：

在启动主类添加注解：@EnableTransactionManagement 来启用注解式事务管理，相当于之前在xml中配置的<tx:annotation-driven />注解驱动。
在需要事务的类或者方法上面添加@Transactional(rollbackFor = Exception.class)注解，里面可以配置需要的粒度：
在逻辑上如果需要手动回滚则加入下代码TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

用法

@**Transactional 可以作用于接口、接口方法、类以及类方法上。**当作用于类上时，该类的所有 public 方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义。
虽然 @Transactional 注解可以作用于接口、接口方法、类以及类方法上，但是 Spring 建议不要在接口或者接口方法上使用该注解，因为这只有在使用基于接口的代理时它才会生效。
另外， ==@Transactional 注解应该只被应用到 public 方法上，这是由 Spring AOP 的本质决定的。==如果你在 protected、private 或者默认可见性的方法上使用 @Transactional 注解，这将被忽略，也不会抛出任何异常。
默认情况下，只有来自外部的方法调用才会被AOP代理捕获，也就是，类内部方法调用本类内部的其他方法并不会引起事务行为，即使被调用方法使用@Transactional注解进行修饰。

@Transactional(readOnly = true)
public class DefaultFooService implements FooService {
    
    

  public Foo getFoo(String fooName) {
    
    
    // do something
  }

  // these settings have precedence for this method
  //方法上注解属性会覆盖类注解上的相同属性
  @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
  public void updateFoo(Foo foo) {
    
    
    // do something
  }
}

java事务学习与扩展