Java事务--JTA原理

        上一篇文章介绍了JDBC事务,JDBC可以处理单数据源的事务,满足大部分事务处理的需求,但是JDBC事务不能解决多数据源和分布式事务问题,Java平台给我们提供了解决方案--JTA。本文将探讨JTA的一些细节。

        一 分布式事务
        通常把一个数据库内部的事务处理,如对多个表的操作,作为本地事务看待。数据库和JDBC的事务处理对象是本地事务,而分布式事务处理的对象是全局事务。
        所谓全局事务,是指分布式事务处理环境中,多个数据库可能需要共同完成一个工作,这个工作即是一个全局事务,例如,一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处,但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功,还要依赖与全局事务相关的其它数据库的操作是否成功,如果任一数据库的任一操作失败,则参与此事务的所有数据库所做的所有操作都必须回滚。
        一般情况下,某一数据库无法知道其它数据库在做什么,因此,在一个 DTP 环境中,交易中间件是必需的,由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作(可恢复)影射到全局事务中,这个环境就是分布式事务处理模型。
        二 XA规范
        X/Open 组织(即现在的 Open Group )定义了分布式事务处理模型。 X/Open DTP 模型( 1994 )包括应用程序( AP )、事务管理器( TM )、资源管理器( RM )、通信资源管理器( CRM )四部分。
        一般常见的事务管理器( TM )是交易中间件,例如JDBC或者hibernate提供的transactionmanager,常见的资源管理器( RM )是数据库,通常就是数据源,例如JDBC或第三方提供的datasource,常见的通信资源管理器( CRM )是消息中间件,如JMS。
        典型的DTP模型如下:

        三 JTA实现
        我们还是以前文提到的转账为例,说明JTA的具体实现。

	<span> public void transferAccount() { 
			
		 UserTransaction userTx = null; 
		 Connection connA = null; 
		 Statement stmtA = null; 
				
		 Connection connB = null; 
		 Statement stmtB = null; 
    
		 try{ 
		       // 获得 Transaction 管理对象
			 userTx = (UserTransaction)getContext().lookup("\
			       java:comp/UserTransaction"); 
			 // 从数据库 A 中取得数据库连接
			 connA = getDataSourceA().getConnection(); 
			
			 // 从数据库 B 中取得数据库连接
			 connB = getDataSourceB().getConnection(); 
      
                        // 启动事务
			 userTx.begin();
			
			 // 将 A 账户中的金额减少 500 
			 stmtA = connA.createStatement(); 
			 stmtA.execute("
            update t_account set amount = amount - 500 where account_id = 'A'");
			
			 // 将 B 账户中的金额增加 500 
			 stmtB = connB.createStatement(); 
			 stmtB.execute("\
             update t_account set amount = amount + 500 where account_id = 'B'");
			
			 // 提交事务
			 userTx.commit();
			 // 事务提交:转账的两步操作同时成功(数据库 A 和数据库 B 中的数据被同时更新)
		 } catch(SQLException sqle){ 
			
			 try{ 
		  	       // 发生异常,回滚在本事务中的操纵
                  userTx.rollback();
				 // 事务回滚:转账的两步操作完全撤销 
				 //( 数据库 A 和数据库 B 中的数据更新被同时撤销)
				
				 stmt.close(); 
                 conn.close(); 
				 ... 
			 }catch(Exception ignore){ 
				
			 } 
			 sqle.printStackTrace(); 
			
		 } catch(Exception ne){ 
			 e.printStackTrace(); 
		 } 
	 }</span>

        注意:我们在上述示例中,使用了两个数据库,即connA 和 connB 是来自不同数据库的连接。
        四 JTA实现原理
         JTA 究竟是通过何种方式来实现事务管理器呢? 要理解 JTA 的实现原理首先需要了解其架构:它包括事务管理器(Transaction Manager)和一个或多个支持 XA 协议的资源管理器 ( Resource Manager ) 两部分, 我们可以将资源管理器看做任意类型的持久化数据存储;事务管理器则承担着所有事务参与单元的协调与控制。 根据所面向对象的不同,我们可以将 JTA 的事务管理器和资源管理器理解为两个方面:面向开发人员的使用接口(事务管理器)和面向服务提供商的实现接口(资源管理器)。其中开发接口的主要部分即为上述示例中引用的 UserTransaction 对象,开发人员通过此接口在信息系统中实现分布式事务;而实现接口则用来规范提供商(如数据库连接提供商)所提供的事务服务,它约定了事务的资源管理功能,使得 JTA 可以在异构事务资源之间执行协同沟通。以数据库为例,IBM 公司提供了实现分布式事务的数据库驱动程序,Oracle 也提供了实现分布式事务的数据库驱动程序, 在同时使用 DB2 和 Oracle 两种数据库连接时, JTA 即可以根据约定的接口协调者两种事务资源从而实现分布式事务。正是基于统一规范的不同实现使得 JTA 可以协调与控制不同数据库或者 JMS 厂商的事务资源,其架构如下图所示:


        开发人员使用开发人员接口,实现应用程序对全局事务的支持;各提供商(数据库,JMS 等)依据提供商接口的规范提供事务资源管理功能;事务管理器( TransactionManager )将应用对分布式事务的使用映射到实际的事务资源并在事务资源间进行协调与控制。 下面,本文将对包括 UserTransaction、Transaction 和 TransactionManager 在内的三个主要接口以及其定义的方法进行介绍。
        面向开发人员的接口为 UserTransaction (使用方法如上例所示),开发人员通常只使用此接口实现 JTA 事务管理,其定义了如下的方法:
         begin()- 开始一个分布式事务
        commit()- 提交事务
        rollback()- 回滚事务
         getStatus()- 返回关联到当前线程的分布式事务的状态
         setRollbackOnly()- 标识关联到当前线程的分布式事务将被回滚
        面向提供商的实现接口主要涉及到 TransactionManager 和 Transaction 两个对象

        Transaction 代表了一个物理意义上的事务,在开发人员调用 UserTransaction.begin() 方法时 TransactionManager 会创建一个 Transaction 事务对象(标志着事务的开始)并把此对象通过 ThreadLocale 关联到当前线程。UserTransaction 接口中的 commit()、rollback(),getStatus() 等方法都将最终委托给 Transaction 类的对应方法执行。

         registerSynchronization(Synchronization sync)- 回调接口,Hibernate 等 ORM 工具都有自己的事务控制机制来保证事务, 但同时它们还需要一种回调机制以便在事务完成时得到通知从而触发一些处理工作,如清除缓存等。这就涉及到了 Transaction 的回调接口 registerSynchronization。工具可以通过此接口将回调程序注入到事务中,当事务成功提交后,回调程序将被激活。

        TransactionManager 本身并不承担实际的事务处理功能,它更多的是充当用户接口和实现接口之间的桥梁。下面列出了 TransactionManager 中定义的方法,可以看到此接口中的大部分事务方法与 UserTransaction 和 Transaction 相同。 在开发人员调用 UserTransaction.begin() 方法时 TransactionManager 会创建一个 Transaction 事务对象(标志着事务的开始)并把此对象通过 ThreadLocale 关联到当前线程上;同样 UserTransaction.commit() 会调用 TransactionManager.commit(), 方法将从当前线程下取出事务对象 Transaction 并把此对象所代表的事务提交, 即调用 Transaction.commit()
        下面将通过具体的代码向读者介绍 JTA 实现原理。下图列出了示例实现中涉及到的 Java 类,其中UserTransactionImpl 实现了 UserTransaction 接口,TransactionManagerImpl 实现了 TransactionManager 接口,TransactionImpl 实现了 Transaction 接口
JTA实现类图如下:




        为什么必须从支持事务的数据源中获得的数据库连接才支持分布式事务呢?其实支持事务的数据源与普通的数据源是不同的,它实现了额外的 XADataSource 接口。我们可以简单的将 XADataSource 理解为普通的数据源(继承了 java.sql.PooledConnection),只是它为支持分布式事务而增加了 getXAResource 方法。另外,由 XADataSource 返回的数据库连接与普通连接也是不同的,此连接除了实现 java.sql.Connection 定义的所有功能之外还实现了 XAConnection 接口。我们可以把 XAConnection 理解为普通的数据库连接,它支持所有 JDBC 规范的数据库操作,不同之处在于 XAConnection 增加了对分布式事务的支持。通过下面的类图读者可以对这几个接口的关系有所了解:




        应用程序从支持分布式事务的数据源获得的数据库连接是 XAConnection 接口的实现,而由此数据库连接创建的会话(Statement)也为了支持分布式事务而增加了功能,如下代码所示:
JTA事务资源处理

<span>public void transferAccount() { 
			
		 UserTransaction userTx = null; 
				
		 Connection conn = null; 
		 Statement stmt = null; 
    
		 try{ 
		        // 获得 Transaction 管理对象
			 userTx = (UserTransaction)getContext().lookup("
			 java:comp/UserTransaction"); 
// 从数据库中取得数据库连接, getDataSourceB 返回支持分布式事务的数据源
			 conn = getDataSourceB().getConnection(); 
                        // 会话 stmt 已经为支持分布式事务进行了功能增强
			 stmt = conn.createStatement(); 
			
                        // 启动事务
			 userTx.begin();
             stmt.execute("update t_account ... where account_id = 'A'"); 
			 userTx.commit();
} catch(SQLException sqle){ 
			 // 处理异常代码
		 } catch(Exception ne){ 
			 e.printStackTrace(); 
		 } 
	 }</span>
五 总结

        JTA的实现其实来源于JDBC的事务,JTA区别于JDBC的是:资源管理器需要实现XADatasource接口,只要实现了这个接口,就可以通过JTA的事务管理器实现事务管理。

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
LINUX下SVN安装,配置,web目录同步 注: 各服务器运行环境可能有所不同,操作过程中可能出现其他问题,自行查阅资料解决 SVN的具体使用方法很多,本文档只是使用了SVN最简单的用法,感兴趣的同学可以查阅相关资料。 一、 安装subversion 首先输入rpm -qa | grep subversion 查看SVN是否已经安装过 如果输出类似如下结果,则说明已经安装:subversion-1.6.11-7.el6.x86_64 执行 yum -y install subversion 安装SVN
一、目录结构 首先是目录结构如图: 二、pom.xml文件 project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd" modelVersion4.0.0/modelVe

Linux内核之进程管理 - 2016-07-23 19:07:13

进程: 进程就是处于执行期的程序以及它包含的资源总和。 线程是进程中的活动对象,每个线程拥有一个独立的程序计数器、进程栈和一组进程寄存器。 内核调度的是线程,而不是进程。 进程描述符: 内核的进程描述符为 task_struct 结构体,定义在linux/sched.h,进程描述符包含了一个进程的所有信息。包括:进程标识符、进程当前状态、栈地址空间、内存地址空间、文件系统、打开的文件、信号量等。 内核把进程的列表存放在叫做 任务列表(task list) 的双向循环链表,链表中每一项都是类型为task_s

SSH权限管理控制到按钮 - 2016-07-23 19:07:11

数据库设计 我的设计如下: 用户:fu_admin 角色:sys_role 权限:sys_purview 用户-角色:sys_user_role 角色-权限:sys_role_purview 标准的权限管理系统设计为以上5张表。 注:用户、用户-角色我就不做说明了,这两个是很简单的两块,用户的crud,以及为用户分配角色(多对多的关系)稍微琢磨一下就清楚了, 下面都是针对为角色分配权限的实现 后台实现 展示层采用ztree树 roleList.jsp !DOCTYPE html PUBLIC "-//W3

docker容器扫盲 - 2016-07-23 18:07:08

Centos 6.5 安装和使用docker 基于本人一贯的习惯,关于“某某某是什么”这样的问题,请百度吧,会有更专业的人士,会比我说的更详细更深,这里我只给出本人亲历的安装和使用过程。 1.安装 先检查服务器环境,docker要求操作系统CentOS6以上,kernel 版本必须2.6.32-431或更高,即=CentOS 6.5,运行docker时实际提示3.8.0及以上,必须64bit,32bit不支持docker。 [root @201 ~] # uname -r 2.6 .32 - 642.1
 原文地址: https://yq.aliyun.com/articles/57901?spm=5176.100239.blogcont57826.25.oaM83B 摘要:   在阿里巴巴在线在线技术峰会上的第三天,来自阿里云高级技术专家李金波为大家题为《企业大数据平台仓库架构建设思路》。本次分享中,李金波主要从总体思路、模型设计、数加架构、数据治理四个方面介绍了如何利用大数据平台的特性,构建更贴合大数据应用的数据仓库。 本文根据阿里云高级技术专家李金波在首届阿里巴巴在线峰会的《企业大数据平台仓库架

linux教程——1.启动过程 - 2016-07-23 17:07:29

Linux  系统启动过程 linux启动时我们会看到许多启动信息。 Linux系统的启动过程并不是大家想象中的那么复杂,其过程可以分为5个阶段: 内核的引导。 运行init。 系统初始化。 建立终端 。 用户登录系统。 内核引导 当计算机打开电源后,首先是BIOS开机自检,按照BIOS中设置的启动设备(通常是硬盘)来启动。 操作系统接管硬件以后,首先读入 /boot 目录下的内核文件。 运行init init 进程是系统所有进程的起点,你可以把它比拟成系统所有进程的老祖宗,没有这个进程,系统中任何进程都
用一种分布式处理方法 挖掘分布式系统检测到的事件联系   点击下载演示文档 abstract: 现在,对监控、分析和控制大规模分布式系统的需求越来越高涨。监控下的事件往往呈现出相关联的关系,这对资源分配、工作调度还有故障预测有很大帮助。为了发现在检测到的事件中的联系,很多已有的方法是把被检测事件放到数据库中并对其进行数据挖掘。但是我们认为这些方法并不适合大规模分布式系统,因为监控事件的数据量增长得非常快以至于很难用一台计算机的力量来进行事件之间联系的发现。在本文中,我们提出了一种分布式的方法有效地检测事件

OSGI中Declarative Services的运用 - 2016-07-23 14:07:48

OSGI中Declarative Services的运用 前言 Declarative Services,即所谓的声明式服务,我在前文中曾经提及到注册式服务与声明式服务,但是在前文中并没有提及怎么使用声明式服务,只是简单的说了下概念和相对于blueprint来说有哪些优缺点,总而言之,可谓是一笔带过,这几日想起这个,还是决定需要仔细的讲一下声明式服务。 简介 Declarative Services,这是在OSGi 4以后的规范中出现的,在这里引用一段其他人说的话,Declarative Services
        我们都希望,配置文件是从一个服务引出,然后客户端监听服务端变化,实时重启自身加载最新配置,这样,我们就不用维护每个独立的客户端配置,更新也变得非常简单,而flume,显然意识到了这一个巨大的实惠,他是支持配置文件交由zookeeper维护的,这样我们在修改配置时,flume会自动重新加载。 1,zookeeper 添加节点         我们利用博客《 使用zkweb维护zookeeper数据 》中介绍的软件,编辑某一个随意路径,用于盛放我们的配置,路径如下: 2,flume 配置zk端