流程引擎执行业务流程，在概念上通常是将流程划分为一些小片段，流程的执行是通过一系列短事务来执行流程片段，片段执行的推进过程就是流程的执行过程，下面具体描述短事务模拟长事务的原理。
事务的属性就是ACID – Atomicity, Consistency, Isolation, Durability，无论短事务还是长事务都应该有这四种属性，短事务的ACID属性由数据库或应用服务器实现，下面主要描述流程长事务的ACID属性是如何通过短事务保证的。
l 流程长事务的原子性（Atomicity）
事务的原子性是指事务中包含的所有操作要么全做，要么全不做（all or none）。
如果每个短事务都是提交的，那么行进到当前片段为止的流程长事务也都是提交的，效果和长事务提交相同。
如果当前短事务回滚，那么流程长事务就不是仅仅回滚这个片段就可以的，但也不是从流程开始的整个长事务都要回滚，从业务的角度来看，通常是要回滚到以前的某个流程结点。
工作流的基本特点就是要忠实记录流程的执行轨迹，站在流程和业务的角度来看，应该是流程实例的控制数据不回滚，只回滚业务数据,这和短事务回滚的内涵是不同的，这也是许多其他流程长事务回滚设计中容易产生的误区，认为要像数据库事务一样回滚。由于在前面的流程片段序列中，业务数据是经持久化了，因此当前流程片段的回滚并不能完整回滚流程业务，只能采用类似于银行冲正的方式来实现，即所谓的“事务补偿”，或者称为“业务补偿”。由于不同的业务其补偿方式也不一样，因此没有一种统一的办法来做业务补偿，只能通过编码的方式来做业务补偿，所能统一的只是业务补偿的接口。在我们的IntelliFlow流程建模中提供了业务补偿的调用接口，可以将业务补偿的模块挂接到流程模型中，也可以在流程引擎的API中调用。
从具体实施的流程应用来看，管理型的业务流程一般不需要做业务补偿，只有在与资金有关的交易型流程中才需要做业务补偿。
l 流程长事务的一致性（Consistency）
在事务开始以前，数据库处于一致性的状态，事务结束后，数据库也必须处于一致性状态。拿银行转账来说，一致性要求事务的执行不应改变A、B 两个账户的金额总和。如果没有这种一致性要求，转账过程中就会发生钱无中生有，或者不翼而飞的现象。事务应该把数据库从一个一致性状态转换到另外一个一致性状态。
由于执行流程片段的短事务保证了数据一致性，因此由短事务组成的流程长事务也是保证数据一致性的。
l 流程长事务的隔离性（Isolation）
事务隔离性要求系统必须保证事务不受其他并发执行的事务的影响，也即要达到这样一种效果：对于任何一对事务T1 和 T2，在事务 T1 看来，T2 要么在 T1 开始之前已经结束，要么在 T1 完成之后才开始执行。这样，每个事务都感觉不到系统中有其他事务在并发地执行。
套用上面的概念，流程长事务的隔离性定义为任意两个流程实例P1和P2并发执行时互相不影响。由于每个流程实例都有唯一的ID，并且在流程引擎设计中，采用了基于流程实例为粒度的锁定机制，因此可以保证流程长事务的隔离性。
l 流程长事务的持久性（Durability）
一个事务一旦成功完成，它对数据库的改变必须是永久的，即便是在系统遇到故障的情况下也不会丢失。
由于执行流程片段的短事务保证了数据的持久性，因此由短事务组成的流程长事务也能保证数据的持久性。
综上所述，流程长事务是可以短事务模拟出来的，并具有现实的可行性，无法像短事务一样采用统一机制自动完成的部分是事务回滚，但是可以根据不同的业务来定制补偿模块来实现，隔离性可以通过在流程引擎中采用统一的机制（以流程实例为粒度进行锁定）自动完成，而一致性和持久性则可以直接通过短事务实现。