JTA 是事务服务的 J2EE 解决方案。本质上，它是描述事务接口(比如 UserTransaction 接口，开发人员直接使用该接口或者通过 J2EE 容器使用该接口来确保业务逻辑能够可靠地运行)的 J2EE 模型的一部分。

JTA 具有的三个主要的接口分别是 UserTransaction 接口、TransactionManager 接口和 Transaction 接口。这些接口共享公共的事务操作，例如 commit() 和 rollback()， 但是也包含特殊的事务操作，例如 suspend()，resume() 和 enlist()，它们只出现在特定的接口上，以便在实现中允许一定程度的访问控制。例如，UserTransaction 能够执行事务划分和基本的事务操作，而 TransactionManager 能够执行上下文管理。本文仅仅需要您对 JTA 有一个基本的了解。

JTA 的好处？

JTA 是一个定义明确的事务服务，向 J2EE 应用程序开发人员提供一种可以直接使用的服务。作为选择，一个应用程序也可能这样部署，容器将代替开发人员来管理事务行为。在后一种情况下，开发人员能够全神贯注于他们的应用程序的业务逻辑，同时由 J2EE 容器来负责事务逻辑。

模型明确的事务服务的好处是对于每个单独的事务总是维持四个 ACID 特性。尽管这是一个实现相关的问题，WebSphere Application Server 提供为每个导入的或者导出的事务保护这些 ACID 特性的能力，而不管并发的事务数目是多少。

JTA 的限制？

经历过所有的事务体系结构，想要有效地将一组事务传送给其他并不共享同样模型的事务服务，同时保持原子的工作单元，是非常困难的。在我们的案例中，建模的 JTA 运行在 Java Transaction Service(JTS) 之上，JTS 处理输入和输出事务传送的请求。

因为 JTS 是一种由 CORBA 定义的对象事务服务(OTS)的 Java 实现，它只能够与另一个 OTS 模型连接。因此， 一个事务只能传送给另一个 OTS-兼容的目标，典型地即另一个 J2EE 实现。因为 JTA 和 JTS 规范没有对这些接口的底层实现加以限制 (只要它们符合模型)，事务可以安全地在两个 J2EE-兼容的应用程序服务器之间传送，而没有丢失它们的 ACID 特性的风险。然而，J2EE 服务器并不必须处理非 J2EE 调用。

某些 J2EE 服务器可能是例外；例如，WebSphere Application Server 将正确地处理一个与 CORBA 兼容事务相关联的输入的 CORBA 请求，将这个事务传送给线程，然后在它的上下文里执行事务工作。然而，在大多数情况下，当您试图在事务模型之间移动的时候，您不得不超越 JTA 和 JTS，把目光投得更远，在这里 Web 服务出现了。

java的事务处理,如果对数据库进行多次操作,每一次的执行或步骤都是一个事务.如果数据库操作在某一步没有执行或出现异常而导致事务失败,这样有的事务被执行有的就没有被执行,从而就有了事务的回滚,取消先前的操作.....

详细说明

Java中使用事务处理，首先要求数据库支持事务。如使用MySQL的事务功能，就要求MySQL的表类型为Innodb才支持事务。否则，在Java程序中做了commit或rollback，但在数据库中根本不能生效。

JavaBean中使用JDBC方式进行事务处理

public int delete(int sID) {
dbc= new DataBaseConnection();
Connection con = dbc.getConnection();
try {
con.setAutoCommit(false);// 更改JDBC事务的默认提交方式
dbc.executeUpdate("delete from xiao where ID=" + sID);
dbc.executeUpdate("delete from xiao_content where ID=" + sID);
dbc.executeUpdate("delete from xiao_affix where bylawid=" + sID);
con.commit();//提交JDBC事务
con.setAutoCommit(true);// 恢复JDBC事务的默认提交方式
dbc.close();
return 1;
}
catch (Exception exc) {
con.rollBack();//回滚JDBC事务
exc.printStackTrace();
dbc.close();
return -1; 　}
}

在数据库操作中，一项事务是指由一条或多条对数据库更新的sql语句所组成的一个不可分割的工作单元。只有当事务中的所有操作都正常完成了，整个事务才能被提交到数据库，如果有一项操作没有完成，就必须撤消整个事务。

例如在银行的转帐事务中，假定张三从自己的帐号上把1000元转到李四的帐号上，相关的sql语句如下：

update account set monery=monery-1000 where name='zhangsan'

update account set monery=monery+1000 where name='lisi'

这个两条语句必须作为一个完成的事务来处理。只有当两条都成功执行了，才能提交这个事务。如果有一句失败，整个事务必须撤消。

在connection类中提供了3个控制事务的方法：

(1) setAutoCommit(Boolean autoCommit):设置是否自动提交事务；

(2) commit();提交事务；

(3) rollback();撤消事务；

在jdbc api中，默认的情况为自动提交事务，也就是说，每一条对数据库的更新的sql语句代表一项事务，操作成功后，系统自动调用commit()来提交，否则将调用rollback()来撤消事务。

在jdbc api中，可以通过调用setAutoCommit(false) 来禁止自动提交事务。然后就可以把多条更新数据库的sql语句做为一个事务，在所有操作完成之后，调用commit()来进行整体提交。倘若其中一项 sql操作失败，就不会执行commit()方法，而是产生相应的sqlexception，此时就可以捕获异常代码块中调用rollback()方法撤消事务。

事务处理是企业应用需要解决的最主要的问题之一。J2EE通过JTA提供了完整的事务管理能力，包括多个事务性资源的管理能力。但是大部分应用都是运行在单一的事务性资源之上(一个数据库)，他们并不需要全局性的事务服务。本地事务服务已然足够(比如JDBC事务管理)。

本文并不讨论应该采用何种事务处理方式，主要目的是讨论如何更为优雅地设计事务服务。仅以JDBC事务处理为例。涉及到的DAO，Factory,Proxy,Decorator等模式概念，请阅读相关资料