業務工作流程平台設計(六)

自訂活動(三)鎖定處理

在前面的文章我已經講過，把使用者資料的收集同工作流程執行個體中分離出來。資料的儲存也就很可能地進行了分離。這種資料的分離會要求我們去做更多的工作：

l  維護工件（如稿件，任務等要在工作流程中進行加工的東西）與工作流程執行個體的關係。我們用WF內建的SqlWorkflowPersistenceService來完成工作流程執行個體的儲存。那麼工件、工件與WF執行個體的關係及相關的處理情況應交給應用系統來維護。有關這方面的內容請看後面的“工作流程的工件維護架構”。

l  保持工件與WF執行個體的狀態一致性。這部分的解決請後後面的有關“狀態一致性”的話題。

l  獨佔式處理。這是本節的重點內容。

獨佔式處理，其實處理過程很簡單，就是在處理時對資料加把鎖，就象進廁所把門鎖上一樣：）。這裡不講怎樣去加鎖，而是講對哪些資料進行加鎖以及何時進行加鎖。

我們來看一下要完成一個審核活動所要處理的資料

l  對工件進行編輯並進行儲存

l  記錄工件的審核情況

l  運行完後儲存WF執行個體的狀態

其實我們需要鎖定的資料只有兩個：工件和WF執行個體。如果工件鎖定不成功的話則應退出WF執行個體的運行，有關如何中止活動的運行，就看後續的文章；如果加鎖成功則直到WF執行個體持久化後再解鎖。注意，雖然WF的SqlWorkflowPersistenceService本身有加鎖的功能，但還是要等到WF執行個體持久化後再對工件解鎖。

這裡有一件事情還要說明。工件在審核過程中可能不會被修改，如果從開啟工件時刻開始加鎖，則會大大的增加佔有時間！切記。我們可以在工件第一次被修改的事件中進行加鎖處理，以儘可能地減少佔有時間。

講到這裡，細心的人可能發現，工件可能在處理過程中沒有被修改，即沒有產生加鎖資訊，此時如果我們運行了WF執行個體，情況是危險的。我們在進行WF時一定要檢測工件是否被鎖定了，如果沒有鎖定則進行加鎖，然後再運行WF執行個體。

先講到這裡，可能有些人嫌我寫的太少了，我只能說對不起了，我還有很多的工作要做。待續。