本文详细介绍了Java中处理事务的方法，包括使用JDBC的简单和复杂事务处理，以及Spring注解的事务管理。讨论了如何在服务方法上使用@Transactional进行回滚控制，并探讨了分布式事务的处理，如JTA、2PC协议以及在J2EE容器中的应用。文章适合Java开发者了解和学习事务处理机制。
1.使用JDBC+RDB处理：
用JDBC的实现的2个方法：
①简单的事务处理
try{
connection.setAutoCommit(false);
//DAO各种操作
connection. commit();
} catch (Exception e) {
connection. rollback();
}
②复杂的事务处理
自己写一个java注解，用动态代理的方法实现编译后跟上面的代码一致，这种方法看着重复性还少一些
http://blog.youkuaiyun.com/huilangeliuxin/article/details/43447091 这个是一个大哥的方法
2.使用Spring注解处理：
在service的方法或者类上加上spring的标注：（因为源码中@Target({ElementType.METHOD, ElementType.TYPE})包括方法或类）
@Transactional(rollbackFor = { RuntimeException.class, Exception.class })
service中出现异常就会回滚
注意3种情况：1.出现异常不想让异常之前的回滚，自己就把出现的异常try catch了
2.没异常但状态不对，想回滚，就自己throw一个异常
3.在controller中记得捕捉异常并按要求做个性化处理
我们公司就是这么做的，对于分布式处理事务的情况，都是在自己负责的service中判断别人的完成传来的参数和状态是否正确（数据验证），
然后再做自己的逻辑，也就是没分布式处理事务，但这种方法也可以保证业务的正确性，就是对业务得熟练。
3.分布式处理事务：
看一看 bao110908 大神的答案：
目前只有 J2EE 容器才能支持分布式事务处理（2012.5）
对于数据库来说，那三个是持 XA 事务的。
建议，在 J2EE 容器上绑定 XA 的 DataSource，并且绑定 JTA 事务。在其他各应用中均使用 JNDI 从 J2EE 容器中获取连接，并开启事务。
这是之前给其他网友回复关于分布式事务的一些内容，有兴趣的话可以看一下：
在 JAVA 中要想使用分布式事务处理，需要使用 JTA。但是 JTA 在 J2SE 环境中是没办法测试的，必须在 J2EE 应用服务器中。
J2EE 应用服务器为什么说会有好的、差的，免费的和商业的，其中最为重要的一点就是对于事务的处理能力。像开源的 J2EE 应用服务器在这一点上是没办法跟 WebLogic, WebSphere 这些商业 J2EE 应用服务器相比拟的。
在 J2EE 环境中使用 JTA 事务与 Local 事务的代码是一模一样的，对于开发人员来说这绝对是希望听到的。
Local 事务就是通常所称的 Connection 的事务。
分布式事务一般采用一种称为 2-PC（两阶段提交）的协议进行处理，2-PC 是分布式事务处理协议。
比如说一个事务涉及 Oracle、MySQL 和 MS SQLServer 三个数据库的操作，举个最简单的例子，要在这三个数据库中各插入一条数据，但必须保持在一个事务中，要三个插入全部成功才算成功，如果只成功了一个或者两个，那么所有的操作都进行回滚，而 2-PC 就是用来干这事的。
两阶段提交需要有个中间协调人。在 Java 中只有 JTA 才能支持两阶段提交，而这个中间协调人就是 J2EE 应用服务器。
继续刚才那个事务，两个阶段如下：
一、各数据库在执行完 INSERT 后，J2EE 应用服务器在收到提交指令，这时通知各数据库进行事务提交准备。
数据库在收到响应后，进行准备工作，基本上是一个预提交工作，如果能提交则响应 J2EE 应用服务器是 能成功提交的，如果无法提交则响应 J2EE 应用服务器是无法提交的。
二、J2EE 应用服务器在收集到所有的响应之后进行判断，如果在第一阶段收到的信息都是可提交的，那么就通知所有的数据库进行提交；如果在第一阶段收到的信息有一个是无法提交的，那么就通知所有的数据库进行回滚操作。
通过这些步骤，可以看出分布式事务处理是很耗时的，也是相当麻烦的。因为数据库在第一阶段给事务协调器响应后如果能提交，在第二阶段就必须要保证事务能被提交，这是数据库要做的事情。
这里的 J2EE 应用服务器是 2-PC 的协调者。2-PC 在 JAVA 中不仅可以用于分布式数据库事务，也能应用于 JMS 事务。
要支持分布式事务，那么数据库就必须支持两阶段提交协议，否则是不能支持的。
以上原理已经很详细了，接着是更详细的图解和例子：
来自 ： http://www.cnblogs.com/yeehuqiu/archive/2012/02/15/2353322.html
引言
JTA(Java Transaction API)允许应用程序执行分布式事务处理--在两个或多个网络计算机资源上访问并且更新数据。JDBC驱动程序的JTA支持极大地增强了数据访问能力。
本文的目的是要提供一个关于的Java事务处理API（JTA）的高级的概述，以及与分布式事务相关的内容。一个事务处理定义了一个工作逻辑单元，要么彻底成功要么不产生任何结果。 一个分布式事务处理只是一个在两个或更多网络资源上访问和更新数据的事务处理，因此它在那些资源之间必然是等价的。在本文中，我们主要关心的是如何处理关系数据库系统。
我们要讨论的分布式事务处理（DTP）模型中包含的组件是：
应用程序
应用程序服务器
事务管理程序
资源适配器
资源管理程序
在以后的内容中，我们将描述这些组件以及它们与JTA和数据库访问的关系。
访问数据库
最好把分布式事务处理中包含的组件看作是独立的过程，而不是考虑它们在一个特定的电脑中的位置。这些组件中的一些可以保存在单机中，或者也可在好几台机器之间分布。 下面例子中的图表可以显示在一台特定的电脑上的组件，但是这些操作之间的关系是必须首要考虑的。
最简单的例子：用于本地数据库事务处理的应用程序
关系数据库访问的最简单的形式仅仅包括应用程序、资源管理程序和资源适配器。应用程序只不过是发送请求到数据库并且从数据库中获取数据的最终用户访问点
我们讨论的资源管理程序是一个关系数据库管理系统（RDBMS），比如Oracle或者SQL Server。所有的实际数据库管理都是由这个组件处理的。
资源适配器是外部空间之间的通信管道组件，或者是请求翻译器，在本例中，是应用程序和资源管理程序。在我们的讨论中，这是一个JDBC驱动程序。
下面的描述是资源管理程序本地事务处理的一个描述，也就是说，一个事务处理被被限制在一个特定的企业数据库。
应用程序发送一个用于JDBC驱动程序数据的请求，然后翻译这个请求并把它通过网络发送到数据库中。 数据库把数据发送回驱动程序，然后把翻译的结果发送回应用程序，如下图所示：
这个例子说明了在一个简化的系统中的基本的信息流；然而，今天的企业使用的应用程序服务器都添加了其他的组件到这个过程处理中。
应用程序服务器
应用程序服务器是事务处理操作的另一个组件。应用程序服务器处理大部分的应用程序操作并且获得最终用户应用程序的一些负载。基于前面的例子，我们可以看出应用程序服务器在事务处理上添加了另一个操作层:
| |
到目前为止，我们的例子说明了单个的本地事务处理，并且描述了分布式事务处理模型的五个组件中的四个。第五个组件，事务管理程序只有当事务将要被分配的时候才会开始被考虑。
分布式事务处理和事务管理程序
像我们前面所提到的，一个分布式事务处理是一个在两个或更多网络资源上访问和更新数据的事务处理。
这些资源可以由好几个位于一个单独服务器上的不同的关系型数据库管理系统组成，比如说Oracle、SQL Server和Sybase；它们也可以包含存在于若干不同的服务器上的同一种数据库的若干个实例。在任何情况下，一个分布式事务处理包括各种的资源管理程序之间的协同作用。这个协同作用是事务管理函数。
事务管理程序负责作出要么提交(commit)要么退回(rollback)任何分布式事务处理的决定。一个提交决定应该导致一个成功的事务处理；而退回操作则是保持数据库中的数据不变。 JTA指定一个分布式事务处理中的事务管理程序和另一个组件之间的标准Java接口：应用程序，应用程序服务器和资源管理程序。 这个关系被显示在下面的图表中：
| |
在事务管理程序周围的数字框框相应于JTA的三个接口部分：
1—UserTransaction—javax.transaction.UserTransaction接口提供能够编程地控制事务处理范围的应用程序。 javax.transaction.UserTransaction方法开启一个全局事务并且使用调用线程与事务处理关联。
2—Transaction Manager—javax.transaction.TransactionManager接口允许应用程序服务器来控制代表正在管理的应用程序的事务范围。
3—XAResource—javax.transaction.xa.XAResource接口是一个基于X/Open CAE Specification的行业标准XA接口的Java映射。
注意，一个限制性环节是通过JDBC驱动程序的XAResource接口的支持。JDBC驱动程序必须支持两个正常的JDBC交互作用：应用程序和/或应用程序服务器，而且以及JTA的XAResource部分。
编写应用程序水平代码的开发者不会关心分布式事务处理管理的细节。 这是分布式事务处理基本结构的工作—应用程序服务器、事务管理程序和JDBC驱动程序。应用程序代码中唯一的需要注意的就是当连接处于一个分布式事务范围内的时候，不应该调用一个会影响事务边界的方法。特别的是，一个应用程序不应该调用Connection方法commit、rollback和setAutoCommit(true)，因为它们将破坏分布式事务的基本结构管理。
分布式事务处理
事务管理程序是分布式事务基本结构的基本组件；然而JDBC驱动程序和应用程序服务器组件应该具备下面的特征：
驱动程序应该实现JDBC 2.0应用程序接口，包括Optional Package接口XADataSource和XAConnection以及JTA接口XAResource。
应用程序服务器应该提供一个DataSource类，用来实现与分布式事务基本结的交互以及一个连接池模块（用于改善性能）。
分布式事务处理的第一步就是应用程序要发送一个事务请求到事务管理程序。虽然最后的commit/rollback决定把事务作为一个简单的逻辑单元来对待，但是仍然可能会包括许多事务分支。一个事务分支与一个到包含在分布式事务中的每个资源管理程序相关联。因此，到三个不同的关系数据库管理的请求需要三个事务分支。每个事务分支必须由本地资源管理程序提交或者返回。事务管理程序控制事务的边界，并且负责最后决定应该提交或者返回的全部事务。 这个决定由两个步骤组成，称为Two - Phase Commit Protocol。
在第一步骤中，事务管理程序轮询所有包含在分布式事务中的资源管理程序（关系数据库管理）来看看哪个可以准备提交。如果一个资源管理程序不能提交，它将不响应，并且把事务的特定部分返回，以便数据不被修改。
在第二步骤中，事务管理程序判断否定响应的资源管理程序中是否有能够返回整个事务的。如果没有否定响应的话，翻译管理程序提交整个事务并且返回结果到应用程序中。
开发事项管理程序代码的开发者必须与所有三个JTA接口有关：UserTransaction、TransactionManager和XAResource，这三个接口都被描述在
Sun JTA specification中。JDBC驱动程序开发者只需要关心XAResource接口。这个接口是允许一个资源管理程序参与事务的行业标准X/Open XA协议的Java映射。连接XAResource接口的驱动程序组件负责在事务管理程序和资源管理程序之间担任"翻译"的任务。下面的章节提供了XAResource调用的例子。
JDBC驱动程序和XAResource
为了简化XAResource的说明，这些例子说明了一个应用程序在不包含应用程序服务器和事项管理程序的情况下应该如何使用JTA。 基本上，这些例子中的应用程序也担任应用程序服务器和事项管理程序的任务。大部分的企业使用事务管理程序和应用程序服务器，因为它们能够比一个应用程序更能够高效地管理分布式事务。 然而遵循这些例子，一个应用程序开发者可以测试在JDBC驱动程序中的JTA支持的健壮性。而且有一些例子可能不是工作在某个特定的数据库上，这是因为关联在数据库上的一些内在的问题。
在使用JTA之前，你必须首先实现一个Xid类用来标识事务（在普通情况下这将由事务管理程序来处理）。Xid包含三个元素：formatID、gtrid（全局事务标识符）和bqual（分支修饰词标识符）。
formatID通常是零，这意味着你将使用OSI CCR（Open Systems Interconnection Commitment, Concurrency和Recovery 标准）来命名。如果你要是用另外一种格式，那么formatID应该大于零。-1值意味着Xid为无效。
gtrid和bqual可以包含64个字节二进制码来分别标识全局事务和分支事务。唯一的要求是gtrid和bqual必须是全局唯一的。此外，这可以通过使用指定在OSI CCR中的命名规则规范来完成。
下面的例子说明Xid的实现：
| import javax.transaction.xa.*; |
其次，你需要创建一个你要使用的数据库的数据源：
| public DataSource getDataSource() |
例1—这个例子是用“两步提交协议”来提交一个事务分支：
| XADataSource xaDS; |
因为所有这些例子中的初始化代码相同或者非常相似，仅仅是一些重要的地方的代码由不同。
例2—这个例子，与例1相似，说明了一个返回过程：
| xaRes.start(xid, XAResource.TMNOFLAGS); |
例3—这个例子说明一个分布式事务分支如何中止，让相同的连接做本地事务处理，以及它们稍后该如何继续这个分支。 分布式事务的两步提交作用不影响本地事务。
| xid = new MyXid(100, new byte[]{0x01}, new byte[]{0x02}); |
例4—这个例子说明一个XA资源如何分担不同的事务。 创建了两个事务分支，但是它们不属于相同的分布式事务。 JTA允许XA资源在第一个分支上做一个两步提交，虽然这个资源仍然与第二个分支相关联。
| xid1 = new MyXid(100, new byte[]{0x01}, new byte[]{0x02}); |
例5—这个例子说明不同的连接上的事务分支如何连接成为一个单独的分支，如果它们连接到相同的资源管理程序。这个特点改善了分布式事务的效率，因为它减少了两步提交处理的数目。两个连接到数据库服务器上的XA将被创建。每个连接创建它自己的XA资源，正规的JDBC连接和语句。在第二个XA资源开始一个事务分支之前，它将察看是否使用和第一个XA资源使用的是同一个资源管理程序。如果这是实例，它将加入在第一个XA连接上创建的第一个分支，而不是创建一个新的分支。 稍后，这个事务分支使用XA资源来准备和提交。
| xaDS = getDataSource(); |
例6—这个例子说明在错误恢复的阶段，如何恢复准备好的或者快要完成的事务分支。 它首先试图返回每个分支；如果它失败了，它尝试着让资源管理程序丢掉关于事务的消息。
| MyXid[] xids; |
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
