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这个执行。所以服务调用可以看做 一个活动实例（活动实例） 是对活动每个执行的唯一实例。

外部实例它们自己负责管理执行锁定。 如果定时器和客户端应用结果是选择 外部实例，而不是直接选择执行，然后在理论上是不必要的。 它是从事活动行为实现，无论它希望 执行锁定还是解锁。