分布式事务及其在OFBiz的实现
分布式事务处理（Distributed Transaction Processing，DTP）是指一个事务可能涉及多个数据库操作，分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。
X/Open 组织（即现在的 Open Group ）定义了分布式事务处理模型。 X/Open DTP 模型（ 1994 ）包括应用程序（ AP ）、事务管理器（ TM ）、资源管理器（ RM ）、通信资源管理器（ CRM ）四部分。一般，常见的事务管理器（ TM ）是交易中间件，常见的资源管理器（ RM ）是数据库，常见的通信资源管理器（ CRM ）是消息中间件。
通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。
所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。对 数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它 数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。
一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。
XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。XA 与两阶段提交协议
通常情况下，交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全局事务， XA 规范的基础是两阶段提交协议。
在第一阶段，交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。当某一数据库收到预 提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，此时数据库将不能再在该事 务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态）。如果由于某种原因数据库无法提交属于自己的 事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。在第二阶段，交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。
以一个全局事务为例， AP 首先通知交易中间件开始一个全局事务，交易中间件通过 XA 接口函数通知数据库开始事务，然后 AP 可以对数据库管理的资源进行操作，数据库系统记录事务对本地资源的所有操作。操作完成后交易中间件通过 XA 接口函数通知数据库操作完成。交易中间件负责记录 AP 操作过哪些数据库（事务分支）。 AP 根据情况通知交易中间件提交该全局事务，交易中间件会通过 XA 接口函数要求各个数据库做预提交，所有数据库返回成功后要求各个数据库做正式提交，此时一笔全局事务结束。
XA 规范对应用来说，最大好处在于事务的完整性由交易中间件和数据库通过 XA 接口控制， AP 只需要关注与数据库的应用逻辑的处理，而无需过多关心事务的完整性，应用设计开发会简化很多。
具体来说，如果没有交易中间件，应用系统需要在程序内部直接通知数据库开始、结束和提交事务，当出现异常情况时必须由专门的程序对数据库进行反向操作才能完成回滚。如果是有很多事务分支的全局事务，回滚时情况将变得异常复杂。而使用 XA 接口，则全局事务的提交是由交易中间件控制，应用程序只需通知交易中间件提交或回滚事务，就可以控制整个事务（可能涉及多个异地的数据库）的全部提交或回滚，应用程序完全不用考虑冲正逻辑。
在一个涉及多个数据库的全局事务中，为保证全局事务的完整性，由交易中间件控制数据库做两阶段提交是必要的。但典型的两阶段提交，对数据库来说事务从开 始到结束（提交或回滚）时间相对较长，在事务处理期间数据库使用的资源（如逻辑日志、各种锁），直到事务结束时才会释放。因此，使用典型的两阶段提交相对 来说会占用更多的资源，在网络条件不是很好，如低速网、网络颠簸频繁，情况会更为严重。
当一个全局事务只涉及一个数据库时，有一种优化方式，即一阶段提交。当 AP 通知交易中间件提交事务时，交易中间件直接要求数据库提交事务，省去两阶段提交中的第一阶段，可以缩短处理一个事务的时间，以提高事务处理的效率。作为两阶段提交的一种特例，与两阶段一样，一阶段提交也是标准的。
XA的要求
对于jms来说，需要配置支持XA的 connection factory.
对于db来说，需使用支持XA的JDBC driver.
两阶段提交(2 phase commit)
先说transaction的管理，如下图。
transaction manager与不同的resource manager都有交互。
在phase1时，transaction manager向两个resouce询问是否可以准备提交。Resouce可回复ready, not_ready或是read_only. 当两个都ready时，则可以进入phase2 进行提交。任何一个回复not_ready则整个transaction 回滚。回复read_only的资源在phase2阶段被排除在提交过程之外。
JTA(Java Transaction API) 为 J2EE 平台提供了分布式事务服务。
要用 JTA 进行事务界定，应用程序要调用 javax.transaction.UserTransaction 接口中的方法。
让我们来关注下面的话：
“用 JTA 界定事务，那么就需要有一个实现 javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC 驱动程序。一个实现了这些接口的驱动程序将可以参与 JTA 事务。一个 XADataSource 对象就是一个 XAConnection 对象的工厂。 XAConnection s 是参与 JTA 事务的 JDBC 连接。”
要使用JTA事务，必须使用XADataSource来产生数据库连接，产生的连接为一个XA连接。
XA连接（javax.sql.XAConnection）和非XA（java.sql.Connection）连接的区别在于：XA可以参与JTA的事务，而且不支持自动提交。
Note:Oracle, Sybase, DB2, SQL Server,MySQL(5.0以后InnoDB存储引擎)等大型数据库才支持XA, 支持分布事务。
3.OFBiz中实现的事务
OFBiz采用 Apache Commons DBCP作为数据库连接池技术，分布式事务是通过Apache Geronimo Transaction实现的。下面是部分实现类关系：
TransactionFactory和ConnectionFactory都可以自己实现并且在entityengine.xml中进行配置，OFBiz中默认配置的是 GeronimoTransactionFactory和DBCPConnectionFactory。OFBiz中实现事务不需要显示调用，在services.xml中的service进行配置，配置的项目有两个require-new-transaction和use-transaction，是否起一个新的事务和是否启用事务，默认是false和true。如果不是采用service，event为java实现，那么需要手动实现事务，通常如下：
beganTransaction = TransactionUtil.begin(DEFAULT_TX_TIMEOUT);
// db operation
return "success";
} catch (Exception e) {
e.printStackTrace();
TransactionUtil.rollback(beganTransaction, e.getMessage(), e);
return " error " ;
} finally {
TransactionUtil.commit(beganTransaction);
}