交易控制與lock實例

今天先將最近遇到第二次交易無法完成的現象寫下，後續再把完整的交易控制觀念補上。

這次是遇到三個系統界接所造成的lock情境:

(使用spring的交易控制)
A=>C=>B
A 系統為觸發的主角、B和C為A系統某個交易控制中各自的一個作業或服務(service)

此交易為A開始後，先呼叫C系統的一個作業，由於C系統的commit動作一律不處理，也就是須由呼叫者A決定是否成立，而B作業是在A呼叫C後的同一個交易控制中的一個作業，這就是說明B和C是綁定在同一個交易控制中，但因為C會因需要更新某個table的資料導致該筆資料是被lock情況(須等解lock )而B作業也會去看該筆資料，造成B需等待C解lock 後才可取到值，可是這是在同一個交易管理中，A因為要等到B完成後才可以commit (解開C的lock)又遲遲等不到，導致畫面就卡住直到A的連線timeout發生錯誤後發生rollback才結束。

等待循環: C等A下commit，B等C解lock，A又等B回應。三方互等就是挨餓狀況!

這種案例是因為三個系統都是不同單位的人負責，大家都不知道彼此做了哪些事，最後要不斷嘗試找到問題點，最終雖將B抽離開本交易流程即可解決，但大公司的系統往往就是會遇到這種罕見的案例。若是很單純ABC都由同一單位的人開發應該就會很清楚這種同一table中資料有修改到就是會發生這種lock。當然也可以怪開發的人隨便把B決定放在此交易中，不過大家也知道這種事難免因為新人或不注意會被引起，解問題就是一門學問和經驗了 !