从源码分析 Spring 基于注解的事务

在spring引入基于注解的事务(@Transactional)之前,我们一般都是如下这样进行拦截事务的配置:

    
    
        
            
            
            
            
            
            
            
            
            
            
            

            
            
            
            
            

            
        
    
    
        
        
    

这种方式明显的缺点是,不太容易理解,并且限定了service层的方法名称的前缀,没有模板的话写起来也很难,很容易写错。

因此在spring中引入了基于注解的事务配置方法之后,我们应该抛弃这种事务配置方法了。基于注解 @Transactional 的事务配置具有简单,灵活的优点。下面看一个例子:

@Service("userService")
@Transactional
public class UserServiceImpl implements UserService{
    @Autowired
    private UserMapper userMapper;
    
    @Transactional (propagation=Propagation.REQUIRED,isolation=Isolation.DEFAULT,readOnly=true)
    public User getUser(int userId) {
        return userMapper.getUser(userId);
    }
    
    @Transactional
    public void addUser(String username){
        userMapper.addUser(username);
//      int i = 1/0;    // 测试事务的回滚
    }
    
    @Transactional (rollbackFor = BaseBusinessException.class)
    public void addAndDeleteUser(String username, int id) throws BaseBusinessException{
        userMapper.addUser(username);        
        this.m1();        
        userMapper.deleteUserById(id);
    }
    
    private void m1() throws BaseBusinessException {
        throw new BaseBusinessException("xxx");
    }
}

首先在service类上声明了@Transactional,表明类中的所有方法都需要运行在事务中,然后在方法中可以指定具体的事务特性,方法中的@Transactional会覆盖类上的@Transactional。

下面我们从源码的角度(从源码的学习可以给我们实打实的比较深入理解,而且不会出错,二手资料总是会有时延的)来探究一下它们:

 public @interface Transactional

注解@Transactional的属性有:propagation, isolation, timeout, readOnly, rollbackFor, rollbackForClassName, noRollbackFor, noRollbackForClassName

propagation, isolation, timeout, readOnly都有默认值,而rollbackFor, rollbackForClassName, noRollbackFor, noRollbackForClassName默认值都是空的。

我们具体看下我们可能会用到的属性:propagation, isolation, readOnly, rollbackFor

1)propagation指定事务的传播属性

 public enum Propagation

propagation可以取如下的值:REQUIRED, SUPPORTS, MANDATORY, REQUIRES_NEW, NOT_SUPPORTED, NEVER, NESTED

我们一般会只用:REQUIRED(默认值), SUPPORTS,其它的取值基本上不使用(具体可以参考上面源码中的注释,已经很详细了)。

propagation=Propagation.REQUIRED:表示该方法或类必须要事务的支持,如果已经是在一个事务中被调用,那么就使用该事务,如果没有在一个事务中,那么就新建一个事务。

propagation=Propagation.SUPPORTS:表示该方法或类支持事务,如果已经是在一个事务中被调用,那么就使用该事务,如果没有在一个事务中,也可以。

2)isolation指定事务的隔离级别

 public enum Isolation

isolation可以取如下的值:DEFAULT, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE

我们一般只使用:DEFAULT(默认值),因为我们一般是直接在数据库的层面上来设置事务的隔离级别,很少会在应用层来设置隔离基本。

isolation=Isolation.DEFAULT:表示使用下层数据库指定的隔离级别

3)readOnly为只读,利于数据库优化器进行优化。默认值为 false。所以对于只对数据库进行读取的方法,我们可以如下指定:

    @Transactional (propagation=Propagation.SUPPORTS)
    public User getUser(int userId) {
        return userMapper.getUser(userId);
    }

表示:有事务则使用当前事务,没有事务则不使用事务。最大限度的利于数据库的优化器进行优化。

如果一定要使用事务的话,也可以这样使用readOnly=true来优化:

    @Transactional (propagation=Propagation.REQUIRED,readOnly=true)
    public User getUser(int userId) {
        return userMapper.getUser(userId);
    }

这就是 readOnly 的作用。表示有事务则使用当前事务,如果没有事务,则新建一个只读事务。其实 上面的 propagation=Propagation.REQUIRED也是可以去掉的,因为他是默认值!

1

2

3

4

@Transactional (readOnly=true)

public User getUser(int userId) {

    return userMapper.getUser(userId);

}

表示强制事务,并且是 只读事务。readOnly 要注意有点的是,readOnly只有在 有事务时,才会生效,如果没有事务,那么 readOnly 是会被忽略的。比如:

@Transactional(propagation=Propagation.SUPPORTS, readonly=true)

表示的就是 没有事务 也是可以的,有事务的话,就一定是 只读事务。

4)rollbackFor,其实该属性也很少使用,而且经常被误用。表示抛出什么异常时,会回滚事务。异常分为受检异常(必须进行处理或者重新抛出)和非受检异常(可以不进行处理)。在遇到非受检异常时,事务是一定会进行回滚的。rollbackFor用于指定对于何种受检异常发生时,进行回滚。因为受检异常,我们必须进行处理或者重新抛出,所以只有一种情况下我们要使用rollbackFor来指定,就是我们不处理异常,直接抛出受检异常,并且我们需要方法在抛出该异常时,进行回滚,如上面的例子:

    @Transactional (rollbackFor = BaseBusinessException.class)
    public void addAndDeleteUser(String username, int id) throws BaseBusinessException{
        userMapper.addUser(username);
        this.m1();
        userMapper.deleteUserById(id);
    }
    private void m1() throws BaseBusinessException {
        throw new BaseBusinessException("xxx");
    }

因为 m1 方法抛出受检异常,我们在 addAndDeleteUser 方法中不对该异常进行处理,而是直接抛出,如果我们希望 userMapper.addUser(username) 和 userMapper.deleteUserById(id) 要么都成功,要么都失败,此时我们则应该指定:rollbackFor = BaseBusinessException.class ,进行回滚。

所以只有我们的方法声明要抛出一个受检异常时,我们才应该使用 rollbackFor 属性来进行处理。如果我们在 addAndDeleteUser  方法中对 m1 方法的受检异常进行了处理,那么就没有必要使用 rollbackFor 了:

    public void addAndDeleteUser(String username, int id){
        userMapper.addUser(username);
        try{
            this.m1();
        }catch(BaseBusinessException e){
            // 处理异常,比如记录进日志文件等
        }
        userMapper.deleteUserById(id);
    }

因为我们处理了 m1 方法的异常,那么就不会有受检异常导致 userMapper.addUser(username) 和 userMapper.deleteUserById(id) 这两个方法一个执行成功,一个没有执行。而非受检异常默认就会回滚。

受检异常是必须进行处理或者重新声明抛出的。只有声明重新抛出受检异常时,才会需要使用 rollbackFor 属性。所以下面的方式就属于滥用 rollbackFor 了:

    @Transactional (rollbackFor=Exception.class)
    public void addAndDeleteUser2(String username, int id){
        userMapper.addUser(username);
        userMapper.deleteUserById(id);
    }

因为:受检异常是必须进行处理或者重新声明抛出,而我们既没有进行处理,也没有重新抛出,就说明他绝对不可能会抛出受检异常了。而只会抛出未受检异常,而未受检异常,默认就会回滚,所以上面的 @Transactional (rollbackFor=Exception.class) 完全是多余的。

总结

1)@Transactional 的默认值为:@Transactional (propagation=Propagation.REQUIRED,isolation=Isolation.DEFAULT,readOnly=false,

timeout=TransactionDefinition.TIMEOUT_DEFAULT),默认值已经适合绝大多数情况,所以我们一般使用 @Transactional 进行注解就够了。

2)只有当默认值不符合我们的需要时才给@Transactional的属性指定值,一般也就指定:propagation=Propagation.SUPPORTS 和 readOnly=true,其它的属性和值一般很少使用非默认值。所以我们前面的UserServiceImpl类可以重构如下:

@Service("userService")
@Transactional
public class UserServiceImpl implements UserService{
    @Autowired
    private UserMapper userMapper;
    
    @Transactional (readOnly=true)
    public User getUser(int userId) {
        return userMapper.getUser(userId);
    }
    
    public void addUser(String username){
        userMapper.addUser(username);
        int i = 1/0;    // 测试事务的回滚
    }
    
    public void deleteUser(int id){
        userMapper.deleteUserById(id);
//      int i = 1/0;    // 测试事务的回滚
    }
    
    @Transactional (rollbackFor = BaseBusinessException.class)
    public void addAndDeleteUser(String username, int id) throws BaseBusinessException{
        userMapper.addUser(username);
        this.m1();
        userMapper.deleteUserById(id);
    }
    
    private void m1() throws BaseBusinessException {
        throw new BaseBusinessException("xxx");
    }
}

addUser 和 deleteUser 因为会继承上的 @Transactional ,所以无需另外指定了,只有当类上指定的 @Transactional 不适合时,才需要另外在方法上进行指定。

3)所以我们只实际情况中,我们只需要使用下面三者来进行注解事务的配置:

@Transactional,

@Transactional (readOnly=true),

@Transactional (propagation=Propagation.SUPPORTS, readOnly=true),

@Transactional (rollbackFor = xxException.class),其它都可以保持默认值,其它的非默认值极少使用。

另外

要使用@Transactional来进行注解事务配置,必须要在spring的配置文件中加入下面的配置说明,启用基于注解的配置:

   
        
    

    
    
   

补充说明

      也许你会觉得奇怪,userMapper.getUser(userId); 这些涉及到数据库访问的方法,为什么不会抛出 SQLException 受检异常呢?如果手动注册驱动,然后获取链接,进行数据库操作时,是会有许多的受检异常要处理的:

        try {
            Class.forName("com.mysql.jdbc.Driver");
        } catch (ClassNotFoundException e) {
            // ...
        }
        String url="jdbc:mysql://localhost:3306/databasename";
         try {
            Connection conn = (Connection) DriverManager.getConnection(url,"username","password");
        } catch (SQLException e) {
            // ...
        } 

哪为什么在这里userMapper.getUser(userId); 就不需要处理受检异常呢?其实这是spring的功能,spring为了将我们从那些十分麻烦的受检异常比如SQLException中解救处理,将所有的数据库访问层的受检异常转嫁到 Spring 的 非受检异常RuntimeException 体系中来——DataAccessException

你可能感兴趣的:(spring,java,数据库)