Distributed Transaction [3] 3.0 JTA Specification

3.0 JTA specification

 2018-02-05 02:31:40  4,908  1

JTA specification Download: http://download.oracle.com/otn-pub/jcp/jta-1.1-spec-oth-JSpec/jta-1_1-spec.pdf

JTA transaction model specification

    Java Transaction API (JTA: Java Transaction API) and its compatriots Java Transaction Service (JTS: Java Transaction Service), provides the ability Distributed Transaction Service (distributed transaction) for the J2EE platform. To some extent, it can be considered JTA XA specification is standardized Java version of its interactive model of the DTP XA Specification defined interfaces to abstract method Java interface, and provides for each method what kind of function to be achieved.

    In the DTP model, the model provides five constituent elements: the application (Application), Resource Manager (Resource Manager), the transaction manager (Transaction Manager), Communication Resource Manager (Communication Resource Manager), communication protocols (Communication Protocol).

    In JTA specification, the addition of a model element Application Server, as follows: 

 

    In the JTA specification, the model tell us about the role of the following individual components:

Transaction Manager (transaction manager):

    The figure in the most central location, all other transaction participants to interact with the transaction manager. The transaction manager provides transaction demarcation, transactional resource management, synchronization, transaction context propagation and other functions. JTA specification defines the interface transaction manager interacts with other participants in the transaction, while JTS specification defines the requirements to achieve transaction manager, so we see the underlying transaction manager is based on the JTS.

 

The application server (application server):

    As the name suggests, it is a container application running. JTA specification, the transaction manager functions should be provided by the application server, such as the image above EJB Server. Some other common web container, such as: jboss, weblogic, websphere, etc., can be used as application server, these web containers have achieved JTA specification. Of particular note is that not all web containers have achieved JTA specification, such as tomcat did not achieve JTA specification, and therefore can not provide a transaction manager functions.

 

App (application):

    Simply put, we have written the application, deployed to achieve the application server JTA specification, then we can we JTA UserTransaction class defined in the specification to declare a distributed transaction. Under normal circumstances, application server to simplify the work of developers, does not necessarily require developers to use UserTransaction to declare a transaction, developers can add a comment on the method requires the use of distributed transactions, like spring's declarative transaction Like, to declare a distributed transaction.

    Of particular note is that, JTA transaction manager specification of functions provided by the application server. But if our application is not a web application, but a local application, does not need to be deployed to the application server, you can not use the transaction manager functions application server provides. Or we use the web container and no transaction manager functions, such as tomcat. For these cases, we can directly use some third-party transaction manager class libraries, such as JOTM and Atomikos. The transaction manager is directly integrated into the application, no longer dependent on the application server.

 

Explorer (resource manager):

    In theory, any software that can store data, can be considered a resource manager RM. The most typical RM is a relational database such as mysql, another relatively common resource manager is messaging middleware, such as ActiveMQ, RabbitMQ, etc. These are real explorer.  

    In fact, the resource manager (resource manager) called resource adapters (resource adapter) seems more appropriate. Since the java program, we are in the RM by client to interact, for example: we driver package by mysql-connector-java-xxxjar, Conn acquisition, perform sql, mysql communicating with the server; by ActiveMQ, RabbitMQ etc. client to send messages.

    Under normal circumstances, a database-driven vendor only need to implement JDBC specification, a messaging middleware vendors need only implement the JMS specification can be. And after the introduction of the concept of distributed transactions, the role of DB, MQ, etc. in the DTP model is RM, the two are equivalent, need to be coordinated by the TM unity.

    To this end, JTA specification defines a XAResource interface, which defines RM must be provided to some of the TM method call. After that, regardless of the RM is DB, or MQ, TM does not care, because its operation is XAResource interface. And other specifications (e.g., JDBC, JMS) implementors, this interface is also implemented. As MysqlXAConnection, to achieve the XAResource interface.

 

Communication resource manager (Communication Resource Manager):

    This is the concept DTP model already exists for the need to communicate with each other across applications require distributed transaction, the transaction manager, which is CRM is through this component to complete. JTA specification, the provisions of CRM need to implement the interface specification defines the JTS.

    The following figure illustrates a more intuitive JTA specification between the various models of how the components interact: 

 

 

described as follows:

1, application running on the application server

2, application needs to access 3 Resource Manager (RM) resources: an MQ resources and two DB resources.

3, since these resources are deployed independently of the server, if the data need to be updated if and to ensure consistency, then you need to use a distributed transaction, a transaction manager is required to harmonization.

4, Application Server provides transaction manager functions

5、作为资源管理器的DB和MQ的客户端驱动包，都实现了XAResource接口，以供事务管理器调用。

2 JTA规范--接口定义

JTA是java扩展包，在应用中需要额外引入相应的jar包依赖

1. <dependency>
2.     <groupId>javax.transaction</groupId>
3.     <artifactId>jta</artifactId>
4.     <version>1.1</version>
5. </dependency>

JTA规范1.1中的源码非常少，如下所示： 

可以看到，这里除了红色框中包含的接口定义之外，其他全部是异常(XxxException)，这里我们仅讨论JTA规范中定义的接口作用：

        javax.transaction.Status：事务状态，这个接口主要是定义一些表示事务状态的常量，此接口无需实现

        javax.transaction.Synchronization：同步

        javax.transaction.Transaction：事务

        javax.transaction.TransactionManager：事务管理器

        javax.transaction.UserTransaction：用于声明一个分布式事务

        javax.transaction.TransactionSynchronizationRegistry：事务同步注册

        javax.transaction.xa.XAResource：定义RM提供给TM操作的接口

        javax.transaction.xa.Xid：事务id

     JTA规范中定义的这些接口，并不需要应用程序的开发人员去实现。而是由各个厂商去实现，根据在DTP模型中扮演的不同角色，需要实现不同的接口。

TM供应商：

    实现UserTransaction、TransactionManager、Transaction、TransactionSynchronizationRegistry、Synchronization、Xid接口，通过与XAResource接口交互来实现分布式事务。此外，TM厂商如果要支持跨应用的分布式事务，那么还要实现JTS规范定义的接口。

    常见的TM提供者包括我们前面提到的application server，包括:jboss、ejb server、weblogic等，以及一些以第三方类库形式提供事务管理器功能的jotm、Atomikos。

RM供应商：

    XAResource接口需要由资源管理器者来实现，XAResource接口中定义了一些方法，这些方法将会被TM进行调用，如：

    start方法：开启事务分支

    end方法：结束事务分支

    prepare方法：准备提交

    commit方法：提交

    rollback方法：回滚

    recover方法：列出所有处于PREPARED状态的事务分支

    一些RM提供者，可能也会提供自己的Xid接口的实现。

   

 此外，不同的资源管理器有一些各自的特定接口要实现：

    如JDBC2.0规范定义支持分布式事务的jdbc driver需要实现：javax.sql.XAConnection、javax.sql.XADataSource接口

    JMS1.0规范规定支持分布式事务的JMS厂商，需要实现javax.jms.XAConnection、javax.jms.XASession接口

 注意：  作为DTP模型中Application开发者的我们，并不需要去实现任何JTA规范中定义的接口，只需要使用TM提供的UserTransaction实现，来声明、提交、回滚一个分布式事务即可。

    以下案例演示了UserTransaction接口的基本使用：构建一个分布式事务，来操作位于2个不同的数据库的数据，假设这两个库中都有一个user表。

1. UserTransaction userTransaction=...
2.         try{
3.             //开启分布式事务
4.             userTransaction.begin(); 
5.            
6.             //执行事务分支1
7.             conn1 = db1.getConnection();
8.             ps1= conn1.prepareStatement("INSERT into user(name,age) VALUES ('tianshouzhi',23)");
9.             ps1.executeUpdate();
10.             
11.             //执行事务分支2
12.             conn2 = db2.getConnection();
13.             ps2 = conn2.prepareStatement("INSERT into user(name,age) VALUES ('tianshouzhi',23)");
14.             ps2.executeUpdate();
15.             //提交，两阶段提交发生在这个方法内部
16.             userTransaction.commit();
17.         }catch (Exception e){
18.             try {
19.                 userTransaction.rollback();//回滚
20.             } catch (SystemException ignore) {
21.             }
22.         }

 

    Note that, in a distributed transaction, when we need to commit or roll back a transaction, should no longer use the commit and rollback methods provided by the Connection interface. Instead, use commit and rollback UserTransaction interfaces interfaces interfaces instead.

    In this case, we did not specify how UserTransaction instance is constructed, which is provided by the Transaction Manager (TM) implementers, and we have not had any contact with the transaction manager.

    In the next section, we will atomikos this transaction manager, to demonstrate a true distributed transaction case.