使用这个范例的好处是相同的流程定义可以在 客户执行模式中执行 （在内存内不使用持久化），就像在持久化执行模式， 依赖应用和环境。

　　当在持久化模式下执行一个流程，你如何绑定 流程执行到数据库的事务上。

　　持久化模式下的事务超时

　　图 5. 持久化模式下的事务超时

　　在大多情况下，计算工作是流程需要完成的一部分， 在外部触发器（红色部分）之后的部分，其实很少。 一般来说，处理流程执行和处理UI传递过来的请求 的事务不会超过一秒。 而业务流程中的等待状态可能超过几小时，几天甚至几年。 当等待状态启动后，线索就变得很清晰， 在等待状态启动之前，只有计算工作的完成包含在事务中。

　　考虑一下这种方式： "当到达审批时，所有的自动流程需要做的是什么， 在流程系统需要等待另一个外部触发器之前？"。 除非pdf需要被创建，或大邮件需要被发送， 大部分时候，它消耗的时间都是可以忽略的。 这就是为什么在默认的持久化执行模式下， 流程工作在客户端线程下执行。

　　这个原因也保证着流程同步路径的情况。 当一个执行的单独路径切分成流程同步路径， 流程花在计算上的时间是可忽略的。 所以为什么分支或切分活动实现是有意义的， 目标持久化模式产生的同步路径在同一个线程中按顺序执行。 基本上它们都只是在同一个事务中的计算工作。 因为分支或切分知道每个执行的同步路径会返回，所以这只能被完成， 当出现一个等待状态的时候。

　　因为这里有一个困难的概念需要掌握，我会再次使用其他词语来解释它。 从头再看一次在持久化执行模式下被流程执行创建出来的它。 如果在一个事务中，一个执行被给与一个外部触发器， 那导致执行切分成多个执行的同步路径。 然后执行在计算上的部分也可以忽略。 生成SQL的部分也可以忽略。 因为所有在同步分支上完成的功能，必须在同一个事务中完成， 这里一般没有指针在分支或切分实现， 在多个线程中产生执行的同步路径。

　　为了创建可执行流程，开发者需要确切知道什么是自动活动， 什么是等待状态，哪些线程会被分配给流程执行。 对于画业务流程的业务分析人员，事件就很简单了。 对于他们画的活动，他们通常只要知道这是一个人或是一个系统响应。 但是他们通常不知道如何转换线程和事务。

　　所以对于开发者，第一个任务是分析什么是流程控制的线程中需要执行的， 什么是外部的。 查找外部触发器是寻找一个流程中的等待状态的很好的开始， 就像动词和名词可以在构建UML类图中的元素的规则。