## 一、與主程序事務沖突問題 典型的，如果我們部署一套主程序，一套jobserver或者workserver等，由于兩者共享同一個數據庫，而兩者由于各自事務中，如果一方有某個長時間事務性(比如循環的全表掃描)的鎖定某張表的操作，而恰恰對方的業務中需要訪問該表，就會拋出 com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction。 解決的方案：將jobserver中，全表掃描的操作，改為短事務，簡單的做法，就是循環全表掃描的過程中，每次操作都是一個完整事務的，而不是全部操作放在一個事務里面，更具體來說，就是事務部放到manager層面，而是放在dao層面。 具體的例子： Manager層面： 事務的：   非事務的：   注意，這里面的dao必須是事務的了，否則，無法修改、刪除、新增實體對象。 Job層面： 事務的：  非事務的：  非事務中，對實體的操作：  但是，這里還是有一個問題，就是由于事務控制在dao層面，會導致每個dao操作都會提交事務，對于每一輪循環操作里面組合了若干個dao操作的，這樣會出現事務臟數據的問題。 解決的方案是： 繼續抽取api，將循環體里面的所有dao操作組合起來，合并為一個api，將事務控制，由原dao層面，提升到該api的事務操作類層面，并將該事務操作類納入applicationContext-*.xml里面，通過serviceLocator.getObjectFromContext獲取即可。  這個方案確保了循環體里面的操作都是完整的事務，循環體之間不是同一個事務，兼顧了事務完整性和避免長事務。 ## 二、事務內死循環問題 死循環的操作，除了上述問題之外，即使是一張獨占的表，還會帶來事務永遠無法提交的問題，所以不能用死循環的方式來處理長時間事務的。 比如：   這個方案里面，由于doTest永遠無法結束，導致內部的事務無法提交，一直處于事務中。故不能采用這種方案，只能是用減小間隔的方式。 ## 三、多job之間事務并發機制 多個job中，如果都循環操作同一個表，會出現臟數據的問題，比如某個job修改后，另外一個job拿到了繼續修改，但由于事務未提交，會出現臟數據。 解決辦法，用數據庫的鎖機制解決。平臺推薦用樂觀鎖，增加版本號來解決沖突。具體可以參考《高級指南》中的樂觀鎖悲觀鎖章節了解； ## 四、全局單一事務job 有時候，有些業務并非長事務，但需要保障業務事務的完整性，平臺提供了一種單一事務job機制。該job里面所有業務邏輯，都在一個事務里面執行，如果執行過程有異常，則會回滾； 具體做法如下： 1、該job與普通job不同，繼承自UniframeworkTimerSingleTransactionJob 2、實現自己的事務內操作，實現自己的SingleTransactionJobOperator類 示例如下：  ## 五、循環獨立事務job 對于長時間的事務，整個job的執行跨度非常長（參考4.1），循環遍歷業務，且每個循環的業務都各自獨立，互補影響，那么，就非常適合用循環獨立事務job，job里面的業務，通過循環來實現，每一輪循環體內的業務，在一個事務里面執行，如果執行過程有異常，則僅循環體內事務回滾，不影響整體job的執行； 具體做法如下： 1、job繼承自UniframeworkTimerJob 2、定義自己的manager，logic及api； 各種定義配置如下：  代碼實現的時候，特別注意，異常的處理，在logic循環內來處理,否則，因為api層面必須拋出異常，才能實現事務回滾，所以不可以在api里面來處理異常，直接讓它拋出即可； 具體的實例明細如下： Job：  Manager:  Logic：  這里是關鍵，這里處理異常，確保不會因為一次失敗，終止整個調度，僅終止該次循環的調度邏輯，而且能確保該次邏輯也是完整事務的，出錯會回滾；這里是在循環體內，捕捉每次api調用的異常； Api：  Api里面，不要處理異常，直接拋出即可； ## 六、跨數據源job 在一個job中，跨兩個數據庫進行操作； 首先、uniframework.properties中配置；  server.jobserver.anotherds.enabled必須設定為true，才會加載； 然后、在job中，調用第二數據源的dao，即可； this.serviceLocator.getJobserverAnotherDatasourceDao() 舉例如下： 核心業務代碼中，這樣來調用第二數據源：