事務優化及一種事務失效的改正

內容來自學成在線的媒資管理事務優化

目前的邏輯是方法uploadFile中包含兩個動作

1 將文件上傳到minio

2 將文件信息存儲到資料庫

原本是整個方法上加@transactional

但是1的這部分, 你並不能保證上傳的時間會有多長

以至於說整個方法如果綁transactional會導致占用資料庫資源

現在有個想法, 打算只在2的步驟上加入transactional

然後在2的程式碼中加入會報錯的程式碼, 看看是否會回滾

部分程式碼

  //將文件上傳到minio
  boolean result = addMediaFilesToMinIO(localFilePath, mimeType, bucket_files, objectName);
  if(!result)XueChengPlusException.cast("上傳文件失敗");
  //文件大小
  uploadFileParamsDto.setFileSize(file.length());
  //將文件信息存儲到數據庫
  MediaFiles mediaFiles = addMediaFilesToDb(companyId, fileMd5, uploadFileParamsDto, bucket_files, objectName);
  if(mediaFiles==null)XueChengPlusException.cast("上傳後保存文件信息失敗");

方法片段

@Transactional
 public MediaFiles addMediaFilesToDb(Long companyId, String fileMd5, UploadFileParamsDto uploadFileParamsDto, String bucket, String objectName) {
  //從數據庫查詢文件
  MediaFiles mediaFiles = mediaFilesMapper.selectById(fileMd5);
  if (mediaFiles == null) {
   mediaFiles = new MediaFiles();
   //拷貝基本信息
   BeanUtils.copyProperties(uploadFileParamsDto, mediaFiles);
   mediaFiles.setId(fileMd5);
   mediaFiles.setFileId(fileMd5);
   mediaFiles.setCompanyId(companyId);
   mediaFiles.setUrl("/" + bucket + "/" + objectName);
   mediaFiles.setBucket(bucket);
   mediaFiles.setFilePath(objectName);
   mediaFiles.setCreateDate(LocalDateTime.now());
   mediaFiles.setAuditStatus("002003");
   mediaFiles.setStatus("1");
   //保存文件信息到文件表
   int insert = mediaFilesMapper.insert(mediaFiles);
   int a=1/0;
   if (insert <=0) {
    log.error("保存文件信息到數據庫失敗,{}", mediaFiles.toString());
    XueChengPlusException.cast("保存文件信息失敗");
   }
   log.debug("保存文件信息到數據庫成功,{}", mediaFiles.toString());

  }
  return mediaFiles;

 }

這時發現雖然會報錯誤, 但是事務沒有回滾, 事務失效

簡單敘述目前狀況

就是controller調用service時, 第一層是調代理對象的方法

但是方法中再調用其他方法, 則會是原對象方法, 如下圖

這裡有個技巧, 可以在方法調service中的方法前加上this.用debug斷點去看this就會發現並非proxy

而這不滿足事務的兩個要求

1 需要是代理對象調方法

2 在調的方法上加@Transactional註解

因為要求沒滿足, 事務沒法生效

課程提供一個解法

就是將當前類再注入進來, 使其變成代理對象

步驟

1 注入本service作為代理對象

@Autowired
MediaFileService currentProxy;

2 將需要事務管理的方法提成接口

public MediaFiles addMediaFilesToDb(Long companyId,String fileMd5,UploadFileParamsDto uploadFileParamsDto,String bucket,String objectName);

3 調用代理對象call方法

//寫入文件表
MediaFiles mediaFiles = currentProxy.addMediaFilesToDb(companyId, fileMd5, uploadFileParamsDto, bucket_files, objectName);

ICUmodle 專案 dropdown出來較其他功能緩慢問題

整串的邏輯大約是這樣

1開始載入時 撈取下拉選單,回給前端排列畫面,並產生全域List供篩選使用

2按鈕功能觸發查詢該病患資料

3依照病患id查詢病患該表項資料

4顯示該病患該表項資料

問題

當4顯示資料的時候, 有去使用到1的下拉選單的List

但是發現, 我操作查詢該病患的表項資料速度快的時候,

會發生顯示問題, 開f12發現, 顯示需要的list並沒有撈回來, 他就已經執行篩選顯示

找尋根源問題

一開始推測, getDropdown需要更多的時間, 所以讓他在網頁中載入順序提前,

但是發現, 這還是沒有解決問題

因此, 我做了一個操作

我嘗試在下拉選單組完選單內容的最後印出"finished"字樣

好讓我知道, 什麼時候才把下拉選單組完

此時我發現, 這個finished差不多讓我等了6秒鐘

很明顯, 如果說我整套操作動作在6秒鐘內完成

很有可能會組資料的時候List還沒有準備好

因此

到底為什麼撈取dropdown會需要撈取這麼久呢?

就是這裡的核心問題

我注意到在等待dropdown回傳的過程中,

他在等待account做了很多查詢

我原本以為是權限相關

回去看code發現

原來為了取得帳號名稱

程式查找出整個account內容

因為其權限是eager撈出來的不是lazyload(當初設計上問題)

因此這邊撈出account會再重新把所有權限功能子功能run一遍

整體就是慢在這邊

解法

我使用另一個只撈id和name的Repo function, 準確的撈取我要的資料->帳號名稱

代替原本把account下面所有關聯查出來

大約看到finished在console中, 不到1秒就跑出來了

而證實拖累效能問題的確在這裡

finished!