X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由这个厂商进行具体的实现

DTP模式规定了三种角色：

• AP：Application应用系统
• TM(协调者)：Transaction Manager事务管理器
• RM(参与者)：Resource Manager资源管理器

三者的关系：

其中在DTP定了以下几个概念：

• 事务：一个事务是一个完整的工作单元，由多个独立的计算任务组成，这多个任务在逻辑上是原子的。
• 全局事务：对于一次性操作多个资源管理器的事务，就是全局事务
• 分支事务：在全局事务中，某一个资源管理器有自己独立的任务，这些任务的集合作为这个资源管理器的分支任务
• 控制线程：用来表示一个工作线程，主要是关联AP,TM,RM三者的一个线程，也就是事务上下文环境。简单的说，就是需要标识一个全局事务以及分支事务的关

整个事务提交分两个阶段：

• 阶段一：表决阶段，所有参与者都将本事务执行预提交，并将能否成功的信息反馈发给协调者
• 阶段二：执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地执行提交或回滚

注：2PC的传统方案是在数据库层面实现的，如Oracle，Mysql都支持2PC协议，为了统一标准减少行业内不必要的对接成本

以上是比较二阶段提交协议正常的情况，但是由于RM有权利自己根据情况提交或者回滚自己的分支事务（官方说法是：Heuristic Decision）那三么就可能出现以下种情况：

1.  在TM通知RM提交事务之前，RM分支事务已经提交
2.  在TM通知RM提交事务之前，RM分支事务全部回滚
3. 在TM通知RM提交事务之前，RM分支事务部分回滚

  对于前面两种情况来说，TM会比较好处理，做事务恢复的时候，要么标记全局事务成功，要么标记全局事务回滚，通知RM可以完成分支事务了，对于第三种情况，可能就需要进行决策了，这个具体怎么处理，DTP并没有说明细节，可以交给开发者自己去判断

DTP本质上只是一个理论基础，它并没有提供具体的实现，往往实现需要考虑更多问题：

• 如何获取TM?
• 如何启动和结束一个事务
• 如何标识一个事务
• 如何保存和传递事务上下文
• 应用如何通过资源管理器操作共享资源
• 资源管理器如何实现准备阶段以及与提交阶段的逻辑
• 如何实现两阶段提交协议
• 如何实现在异常情况下进行事务恢复

基于DTP模型的方案有TCC，AT，Sage，XA都基于这个DTP模型(二阶段提交协议)

DTP二阶段提交协议的弊端：

• 单点问题：以事务协调者为中心，假如它挂了就没办法了
• 同步堵塞：延迟了提交时间，加长了资源堵塞时间
• 数据不一致：提交二阶段，依然存在commit结果未知的情况，有可能导致数据不一致