Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 JDBC Adapter支持三种事务工作模式：无事务、本地事务(Local Transaction)、全局事务(XA Transaction)。下面将分别介绍各种事务工作模式。

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4

无事务

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4

  无事务也就是说所有操作不会参与到任何事务中，因此数据的操作的事务完整性不会得到任何保证。在这种模式下，如果在一个服务中同时插入/更新多条记录，服务会一直执行直到所有操作完成或者其中某个操作失败为止，并且已经执行的操作不会因为后面操作的失败而回滚。因此如果记录间存在业务逻辑关系那么一个服务执行失败可能是灾难性的，因为它可能会破坏数据的完整性。这在实际应用中往往是不能容忍的。因此实际应用中不建议将Adapter配置成无事务模式。

    如果使用JDBC连接URL及用户名/密码方式配置数据库连接，只要将AutoCommit的值设置为true，那么JDBC Adapter将会工作在无事务支持模式下。如下图所示：

图1. 设置

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4

    我们用一个简单的测试来说明无事务支持对数据的影响：

图2. Oracle Create数据

    如上图所示，我们尝试创建一个客户信息和客户扩展信息，它们业务逻辑上存在一一对应关系，不过数据库中并没有创建外键约束，因此希望由JDBC Adapter来维护逻辑关系。但由于客户关系的信息错误，某字段超过数据库的长度限制，因此调用服务将会失败，如下图所示：

图3. 测试Oracle Create执行结果

让我们来检查一下数据库中的记录：

select * from customer;
select * from custinfo

执行结果如下：

CUSTOMERID           NAME                 ADDR                 EMAIL       
-------------------- -------------------- -------------------- ------------

0 rows selected

CUSTOMERID           COMPANY              PHONE                CUSTOMERTYPE        
-------------------- -------------------- -------------------- --------------------
1                    IBM                  010-88888888         2                   

1 rows selected

    可以看到客户扩展信息被写到数据库中，而客户信息没有被写到数据库中，这破坏了数据的完整性，并不是我们所期望的结果。

本地事务(Local Transaction)

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4

    本地事务在一个应用/模块内部开始和结束事务，而且只有一个数据库/模块参与到事务中，本地事务模式使用一阶段提交。如果Adapter采用本地事务模式，那么一个服务中所有操作会在同一个事务中执行。因此只要服务中有任何一个数据库操作失败，整个事务将会回滚，它可以保证所有单次服务内的事务完整性。因此，对于不需要跨数据库/组件事务完整性的应用可以使用本地事务模型。

有两种连接配置方式可以使JDBC Adapter工作在本地事务模式下：

1. 使用连接URL和用户名/密码配置数据库连接，如图1所示，但将AutoCommit属性值设为false。

图4. 配置JDBC Adapter使其通过JNDI名查找数据源

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4     运行与图2相同的的测试例子，同样因为客户信息数据异常，测试执行失败，但检查数据库如下：

select * from customer;
select * from custinfo

执行结果如下：

CUSTOMERID           NAME                 ADDR                 EMAIL       
-------------------- -------------------- -------------------- ------------

0 rows selected

CUSTOMERID           COMPANY              PHONE                CUSTOMERTYPE        
-------------------- -------------------- -------------------- --------------------

0 rows selected

    我们发现由于第二条记录插入失败导致事务回滚，第一条记录并没有插入到数据库中，这是我们期望的结果。由此可以看出本地事务模式可以保证一次服务请求内部对同一个数据库操作的事务完整性。

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4

    虽然本地事务可以解决一个数据库内的事务完整性，但如果一个服务需要保证两个或以上数据库的事务完整性，本地事务则无能为力，下面以一个例子说明本地事务的局限性，如下图所示：

图5. 多数据库支持的服务调用关系

    我们在Oracle数据库中创建客户信息的同时需要向DB2中插入一条操作日志信息，而且这些操作要求能够保证事务完整性。由于底层数据库连接不支持全局事务，因此我们需要确认Oracle组件及DB2组件都不会加入到全局事务控制中（需要注意的是，由于底层数据库连接不支持全局事务，相应组件的服务不能加入到全局事务中，否则当事务管理器尝试进行全局事务控制时，由于底层驱动不支持而导致操作失败服务不可用），如下图所示：

图6. 确认Oracle和DB2的服务

     运行测试数据如下：

图7. 同时向Oracle和DB2内插入数据的测试数据

    由于程序/输入出现异常，操作日志中不能为空的字段operation的值被设置为空了，因此操作将会失败如下：

图8. 因为DB2数据异常，服务调用失败

检查数据库我们将会发现客户数据被插入到Oracle数据库中，这并不是我们期望的结果：

select * from customer;
select * from custinfo

CUSTOMERID           NAME                 ADDR                 EMAIL       
-------------------- -------------------- -------------------- ------------
1                    customer1            Beijing                          

1 rows selected

CUSTOMERID           COMPANY              PHONE                CUSTOMERTYPE        
-------------------- -------------------- -------------------- --------------------
1                    IBM                  010-88888888         2                   

1 rows selected