事务场景中，抛出异常被catch后，如果需要回滚，一定要手动回滚事务

阿里巴巴《Java开发手册》：事务场景中，抛出异常被catch后，如果需要回滚，一定要手动回滚事务。

今天装了一个ali编码规约插件，在对工程做编码规约扫描时，也给出了这个提示。

 

 

汇票系统，下述发布贴现方法，要求先创建票据再创建贴现交易，整体是一个spring事务。如果不加异常捕获，那么一旦程序执行出现RuntimeException后，AOP捕获异常后默认会先回滚事务再throw，只不过这样对调用方（有时）不“友好”； 加了try..catch捕获到异常后，如果不显式回滚，那么，前面的“创建票据”就提交到db了，所以，为保证事务的一致性，就要手动回滚事务，并返回创单失败。

显式回滚事务： TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

public class TradeOrderServiceImpl{
    @Autowired
    TradeOrderServiceImpl tradeOrderService;

    @Autowired
    DraftInfoServiceImpl draftInfoService;
    
    /**
     * 发布贴现
     *
     */
    @Transactional
    public ResponseModel publish(String merId, String openBank, BigDecimal amt){
        DraftInfoModel draftInfoModel = new DraftInfoModel();
        draftInfoModel.setMerchantId(merId);
        draftInfoModel.setAmt(amt);
        ... ...
        // 持久化票据记录
        DraftInfoModel res_draftInfoModel = draftInfoService.addDraftInfo(draftInfoModel);
        
        try{
            TradeOrderModel tradeOrderModel = new TradeOrderModel();
            tradeOrderModel.setSellerMerchantId(merId);
            tradeOrderModel.setOpenBank(openBank); //openBank超长会导致mySQL的Data truncated for column异常。
            tradeOrderModel.setPlatFeeAmt(amt);
            tradeOrderModel.setDraftId(res_draftInfoModel.getDraftId());
            ... ...
            // 持久化贴现交易记录
            TradeOrderModelRes tradeOrderModelRes = tradeOrderService.publishDraftDiscount(tradeOrderModel);
        }catch(Exception e){
            // 手动回滚事务
            TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
            // 返回创单失败
            return new ResponseModel(false, ExceptionUtils.getMessage(e));
        }
        
        // 返回创单完成
        return new ResponseModel(true);
    } 
}

 

 

如下testcase作用是新增转账原因，使用@Transactional注解开启了事务，当执行第二个insert时，由于数据超长报异常：### Error updating database. Cause: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'transfer_reason' at row 1。此时会整体回滚事务，两个转账原因都未持久化，保证了事务的ACID。

@Test
@Transactional
public void insertTransferReason(){
    List<BatchPayRecordDetail> batchPayRecordDetails = batchPayRecordDetailMapper.selectByExample(new BatchPayRecordDetailExample());
    if(CollectionUtils.isEmpty(batchPayRecordDetails)){
        Assert.fail("no data");
    }
    String auditMan="test";
    BatchPayRecordDetail recordDetail=batchPayRecordDetails.get(0);
    System.out.println("==============================");

    recordDetail.setPayReason(UUID.randomUUID().toString());
    int i1 = managerBll.insertTransferReason(recordDetail, auditMan);
    System.out.println(i1);

    recordDetail.setPayReason(UUID.randomUUID().toString()+"测试(String), 39c535de-79ff-4fc4-a514-5c431ad4157d2019-04-04 11:26:43,147 DEBUG [main] (BaseJdbcLogger.java:145) 6219 - ==>  Preparing: insert into transfer_account_reason (transfer_reason_(String), 0(String), SUCCES(String), test(String), null, null\n" +
            "2019-04-04 11:28:42,975 DEBUG [main] (BaseJdbcLogger.java:145) 6611 - <==    Updates: 1");
    int i = managerBll.insertTransferReason(recordDetail, auditMan);
    System.out.println(i);
}