PROPAGATION_REQUIRED： 默认支持
PROPAGATION_SUPPORTS： 默认支持
PROPAGATION_MANDATORY：应用通过 API 来实现
PROPAGATION_REQUIRES_NEW：应用通过 API 来实现
PROPAGATION_NOT_SUPPORTED：应用通过 API 来实现
PROPAGATION_NEVER：应用通过 API 来实现
PROPAGATION_REQUIRED_NESTED：不支持
3.5 隔离性
全局事务的隔离性是建立在分支事务的本地隔离级别基础之上的。
在数据库本地隔离级别 读已提交 或以上的前提下，Fescar 设计了由事务协调器维护的 全局写排他锁，来保证事务间的 写隔离，将全局事务默认定义在 读未提交 的隔离级别上。
我们对隔离级别的共识是：绝大部分应用在 读已提交 的隔离级别下工作是没有问题的。而实际上，这当中又有绝大多数的应用场景，实际上工作在 读未提交 的隔离级别下同样没有问题。
在极端场景下，应用如果需要达到全局的 读已提交，Fescar 也提供了相应的机制来达到目的。默认，Fescar 是工作在 读无提交 的隔离级别下，保证绝大多数场景的高效性。
事务的 ACID 属性在 Fescar 中的体现是一个比较复杂的话题，我们会有专门的文章来深入分析，这里不做进一步展开。
4. 适用场景分析
前文所述的 Fescar 的核心原理中有一个 重要前提：分支事务中涉及的资源，必须 是支持 ACID 事务的 关系型数据库。分支的提交和回滚机制，都依赖于本地事务的保障。所以，如果应用使用的数据库是不支持事务的，或根本不是关系型数据库，就不适用。
另外，目前 Fescar 的实现还存在一些局限，比如：事务隔离级别最高支持到 读已提交 的水平，SQL 的解析还不能涵盖全部的语法等。
为了覆盖 Fescar 原生机制暂时不能支持应用场景，我们定义了另外一种工作模式。
上面介绍的 Fescar 原生工作模式称为 AT（Automatic Transaction）模式，这种模式是对业务无侵入的。与之相应的另外一种工作模式称为 MT（Manual Transaction）模式，这种模式下，分支事务需要应用自己来定义业务本身及提交和回滚的逻辑。
4.1 分支的基本行为模式
作为全局事务一部分的分支事务，除本身的业务逻辑外，都包含 4 个与协调器交互的行为：
分支注册： 在分支事务的数据操作进行之前，需要向协调器注册，把即将进行的分支事务数据操作，纳入一个已经开启的全局事务的管理中去，在分支注册成功后，才可以进行数据操作。
状态上报： 在分支事务的数据操作完成后，需要向事务协调器上报其执行结果。
分支提交：响应协调器发出的分支事务提交的请求，完成分支提交。
分支回滚：响应协调器发出的分支事务回滚的请求，完成分支回滚。
4.2 AT 模式分支的行为模式
业务逻辑不需要关注事务机制，分支与全局事务的交互过程自动进行。
4.3 MT 模式分支的行为模式
业务逻辑需要被分解为 Prepare/Commit/Rollback 3 部分，形成一个 MT 分支，加入全局事务。
MT 模式一方面是 AT 模式的补充。另外，更重要的价值在于，通过 MT 模式可以把众多非事务性资源纳入全局事务的管理中。
4.4 混合模式
因为 AT 和 MT 模式的分支从根本上行为模式是一致的，所以可以完全兼容，即，一个全局事务中，可以同时存在 AT 和 MT 的分支。这样就可以达到全面覆盖业务场景的目的：AT 模式可以支持的，使用 AT 模式；AT 模式暂时支持不了的，用 MT 模式来替代。另外，自然的，MT 模式管理的非事务性资源也可以和支持事务的关系型数据库资源一起，纳入同一个分布式事务的管理中。
4.5 应用场景的远景
回到我们设计的初衷：一个理想的分布式事务解决方案是不应该侵入业务的。MT 模式是在 AT 模式暂时不能完全覆盖所有场景的情况下，一个比较自然的补充方案。我们希望通过 AT 模式的不断演进增强，逐步扩大所支持的场景，MT 模式逐步收敛。未来，我们会纳入对 XA 的原生支持，用 XA 这种无侵入的方式来覆盖 AT 模式无法触达的场景。
5. 扩展点
5.1 微服务框架的支持
事务上下文在微服务间的传播需要根据微服务框架本身的机制，订制最优的，对应用层透明的解决方案。有兴趣在这方面共建的开发者可以参考内置的对 Dubbo 的支持方案，来实现对其他微服务框架的支持。