測試@Transactional的在處理異常時是否生效，

首先這裡隨便寫一個update的方法，對資料庫進行更新操作，然後在操作完之後拋一個異常

@Override
    @Transactional(rollbackFor = {Exception.class})
    public String alterUser(){
        try {
            User user=new User();
            user.setId(2);
            user.setUsername("updateUserTest");
            userMapper.updateByPrimaryKeySelective(user);
            int i=1/0;
            return "success";
        }catch (Exception e){
            return "false";
        }
    }
 

這裡在update完之後，拋一個ArithmeticException（除0），按照我們設想的，這裡出現了異常，然後事務回滾，更新不會生效

，然後我們測試一下

原來資料庫中的記錄是這樣的

這裡我們寫的介面，返回了false，說明是補獲到異常了。

然後看下資料庫

這裡可以看到記錄還是被修改了，事務沒有回滾。

然後我們將異常丟擲去，不處理

在控制器中處理

@Override
    @Transactional(rollbackFor = {Exception.class})
    public String alterUser() throws Exception{
        try {
            User user=new User();
            user.setId(2);
            user.setUsername("updateUser");
            userMapper.updateByPrimaryKeySelective(user);
            int i=1/0;
            return "success";
        }catch (Exception e){
            throw new Exception(e.getMessage());
        }
    }
 

@RequestMapping(value = "/W0003")
    @ResponseBody
    public String W0003(HttpServletRequest request){
        try {
            return userService.alterUser();
        }catch (Exception e){
            return e.getMessage();
        }
    }

這裡繼續測試一下，結果如下

看下資料庫

發現數據沒有被修改，說明回滾成功。

由此可以推知，在spring中如果某個業務方法被一個 整個try catch包裹起來，則這個業務方法也就等於脫離了spring事務的管理，因為沒有任何異常會從業務方法中丟擲！全被捕獲併吞掉，導致spring異常丟擲觸發事務回滾策略失效。  不過，如果在catch程式碼塊中採用頁面硬編碼的方式使用spring api對事務做顯式的回滾，這樣寫也未嘗不可。