7.6. 流程同步

為了進行流程同步建模，在執行中這是一個父子樹形結構。 這個想法是執行主路徑是樹的根。 流程的主路徑也被稱作流程實例。 當在給定流程定義上啟動或創建一個新流程實例時， 執行便被創建。

現在，因為執行的主路徑和流程實例是相同對象， 這保證了用法的簡單， 在沒有同步情況的簡單流程下。
基本執行結構的UML類圖



圖 7.6. 基本執行結構的UML類圖

為了建立執行的多同步路徑，活動實現比如一個分支或切分 創建子執行， 使用ActivityExecution.createExecution方法。 活動實現比如結合或合并可以停止流程的這些同步路徑， 通過調用執行同步的stop方法。

只有葉子執行可以激活，非葉子執行應該不是激活的。 這個執行的樹形結構沒有堅持一個同步或結合行為的特殊類型。 它從事著分支或和切分 和結合或和合并來使用執行樹結構， 用任何方式，他們想定義期望的同步行為。 這里我們看一個同步執行的例子。
執行的同步路徑



圖 7.7. 執行的同步路徑

這里有執行的一個付款和一個發貨路徑。 在這種情況，水平線上的活動展示了分支和結合。這個執行顯示了三個執行。 執行的主路徑不是激活的（顯示成灰色） 執行的付款和發貨路徑是激活的，分別指向了 bill和ship活動。

從事活動行為的實現，是他們想使用的執行結構。 假設多個任務必須在執行進行之前完成。 活動行為可以為這個產生一系列子執行。 或者可以選擇，任務組件可以支持任務組， 分配給單獨的執行。在那種情況， 任務組件成為同步任務的響應， 因此把這個責任移動到執行樹形結構范圍之外。
7.7. 異常處理器

在所有分配到流程的代碼中，像 Activity，EventListeners和 Condition，可能分配給異常處理器。 這可以想成是把這些實現的方法實現包含在try-catch塊中。 但是為了構建更多可復用的構建塊， 為了委派類和異常處理邏輯， 異常處理器可以添加到核心流程模型中。

一個異常處理器可以分配給任何流程元素。 當一個異常發生在一個委派類中，一個匹配的異常處理器就會被找到。 如果找到了一個這樣的異常處理器，它會有一個處理這個異常的機會。

如果一個異常處理器處理完成，沒有出現問題，然后這個異常會 被認為是處理了，就會在委派代碼調用后繼續。 比如，一個轉移有三個動作，第二個動作拋出一個異常， 這個異常被異常處理器處理，然后

編寫自動活動，異常處理器提醒是很容易的。 默認是任意執行。沒有方法需要在執行中調用。 所以如果一個自動活動拋出一個異常，被異常處理器處理， 這個執行會在這個執行后繼續執行。這對于控制流向活動 就會有一個更大的困難。它們可能需要包含try-finally塊 來調用執行中對應的方法，在異常處理器 獲得一個機會來處理異常。比如，如果活動是等待狀態， 然后發生了一個異常，這里就會有一個風險，線程會跳出 execution.waitForSignal()的調用， 導致執行在這個活動以后繼續執行。

TODO: exceptionhandler.isRethrowMasked

TODO: transactional exception handlers

TODO: we never catch errors
7.8. 流程修改

TODO: 流程修改
7.9. 鎖定和流程狀態

一個執行的狀態不是激活就是鎖定。 一個激活的執行不是執行就是等待外部觸發器。 如果一個執行不是STATE_ACTIVE，那么它就是被鎖定。 一個鎖定的執行是只讀的，不能接受任何外部觸發器。

當一個新執行被創建時，它是STATE_ACTIVE。 為了把狀態修改成鎖定狀態，使用lock(String)。一些STATE_*常量 被提供了，它們演示了最常用的鎖定狀態。 但是在圖片中的'...'狀態展示了任何字符串 都可以作為狀態提供給lock方法。
執行的狀態



圖 7.8. 執行的狀態

如果一個執行被鎖定，修改執行的方法會 拋出一個PvmException，信息會引用真實的鎖定狀態。 觸發事件，更新變量，更新優先級，添加注釋 不會當做是修改執行。 子節點的創建和刪除也不會檢測， 這意味著那些方法可以被外部API客戶和活動行為調用， 即使執行在鎖定狀態。

確保比較getState()和STATE_*常量時 使用.equals，不要使用'=='，因為如果執行從持久存儲加載。 會創建一個新字符串，而不是使用常量。

一個執行實現會被鎖定：

    * 當它結束
    * 當它暫停
    * 在異步延續過程中

更多的，鎖定可以被活動實現使用， 讓執行在等待狀態下只讀，然后為這個執行傳遞 的外部實例就像這樣：

    * 一個人員任務
    * 一個服務調用
    * 一個等待狀態當探測器檢測一個文件的出現時就結束

在這些情況，策略是外部實例應該獲得 執行的完全控制，因為它想要控制什么應該允許，什么不應該。 為了獲得那種控制，他們鎖定了執行，所以所有內部交互 必須通過外部實例傳遞。

一個創建外部實例的主要原因是， 它們可以在執行已經執行過還存在。比如， 在服務調用的情況，定時器可以導致執行獲得超時轉移。 當響應在超時后到達，服務調用實例應該 確認它沒有signal這個執行。所以服務調用可以看做 一個活動實例（活動實例） 是對活動每個執行的唯一實例。

外部實例它們自己負責管理執行鎖定。 如果定時器和客戶端應用結果是選擇 外部實例，而不是直接選擇執行，然后在理論上是不必要的。 它是從事活動行為實現，無論它希望 執行鎖定還是解鎖。