http://apzx2007.blog.163.com/blog/static/70507440200910236014880/
在JDBC的数据库操作中，一项事务是由一条或是多条表达式所组成的一个不可分割的工作单元。我们通过提交commit()或是回退rollback()来结束事务的操作。关于事务操作的方法都位于接口java.sql.Connection中。
首先我们要注意，在JDBC中，事务操作默认是自动提交。也就是说，一条对数据库的更新表达式代表一项事务操作。操作成功后，系统将自动调用commit()来提交，否则将调用rollback()来回退。
其次，在JDBC中，可以通过调用setAutoCommit(false)来禁止自动提交。之后就可以把多个数据库操作的表达式作为一个事务，在操作完成后调用commit()来进行整体提交。倘若其中一个表达式操作失败，都不会执行到commit()，并且将产生响应的异常。此时就可以在异常捕获时调用rollback()进行回退。这样做可以保持多次更新操作后，相关数据的一致性。示例代码如下：
java 代码
try {
conn = DriverManager.getConnection("jdbc:microsoft:sqlserver://localhost:1433;User=JavaDB;Password=javadb;DatabaseName=northwind);
//点禁止自动提交，设置回退
conn.setAutoCommit(false);
stmt = conn.createStatement();
//数据库更新操作1
stmt.executeUpdate(“update firsttable Set Name=‘testTransaction‘ Where ID = 1”);
//数据库更新操作2
stmt.executeUpdate(“insert into firsttable ID = 12，Name = ‘testTransaction2‘”);
//事务提交
conn.commit();
}
catch(Exception ex) {
ex.printStackTrace();
try {
//操作不成功则回退
conn.rollback();
}
catch(Exception e){
e.printStackTrace();
}
}
这样上面这段程序的执行，或者两个操作都成功，或者两个都不成功，读者可以自己修改第二个操作，使其失败，以此来检查事务处理的效果。我们在前面还提到了JDBC对事务所支持的隔离级别，下面将更详细进行讨论。
JDBC API支持事务对数据库的加锁，并且提供了5种操作支持，2种加锁密度。
5种加锁支持为：
static int TRANSACTION_NONE = 0;
static int TRANSACTION_READ_UNCOMMITTED = 1;
static int TRANSACTION_READ_COMMITTED = 2;
static int TRANSACTION_REPEATABLE_READ = 4;
static int TRANSACTION_SERIALIZABLE = 8;
具体的说明见表4-2。
2种加锁密度：
最后一项为表加锁，其余3～4项为行加锁。
“脏”数据读写(Dirty Reads)：当一个事务修改了某一数据行的值而未提交时，另一事务读取了此行值。倘若前一事务发生了回退，则后一事务将得到一个无效的值(“脏”数据)。
重复读写(Repeatable Reads)：当一个事务在读取某一数据行时，另一事务同时在修改此数据行。则前一事务在重复读取此行时将得到一个不一致的值。
错误(映像)读写(Phantom Reads)：当一个事务在某一表中进行数据查询时，另一事务恰好插入了满足了查询条件的数据行。则前一事务在重复读取满足条件的值时，将得到一个额外的“影像”值。JDBC根据数据库提供的默认值来设置事务支持及其加锁，当然，也可以手工设置：
setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED);
可以查看数据库的当前设置：
getTransactionIsolation ()
需要注意的是，在进行手动设置时，数据库及其驱动程序必须得支持相应的事务操作操作才行。
上述设置随着值的增加，其事务的独立性增加，更能有效地防止事务操作之间的冲突，同时也增加了加锁的开销，降低了用户之间访问数据库的并发性，程序的运行效率也会随之降低。因此得平衡程序运行效率和数据一致性之间的冲突。一般来说，对于只涉及到数据库的查询操作时，可以采用TRANSACTION_READ_UNCOMMITTED方式；对于数据查询远多于更新的操作，可以采用TRANSACTION_READ_COMMITTED方式；对于更新操作较多的，可以采用TRANSACTION_REPEATABLE_READ；在数据一致性要求更高的场合再考虑最后一项，由于涉及到表加锁，因此会对程序运行效率产生较大的影响。
另外，在Oracle中数据库驱动对事务处理的默认值是TRANSACTION_NONE，即不支持事务操作，所以需要在程序中手动进行设置。总之，JDBC提供的对数据库事务操作的支持是比较完整的，通过事务操作可以提高程序的运行效率，保持数据的一致性。
4.8.4 分布式事务处理
在本节大部分篇幅中，我们一直讨论的事务一直是仅仅涉及单个数据库相连的单条连接，下面对分布式事务进行简单的介绍。
事务处理是对某种服务的请求，而且是否接受或拒绝这种请求将即时答复请求者。在请求和响应之间，资源(如文件、数据库等)将根据需要阅读和更新。从事务处理的发展历史来看，大致经历了一个从集中处理到分布式处理的演进过程。这一转变主要的动力是伴随着Internet的兴起，客户对于更快、更安全的事务处理的客观需求和面向对象的应用所提供的技术实现的可能性。
在Internet环境下，分布式事务处理为了满足日益巨大的业务吞吐量所带来的挑战，其功能必须进一步拓展，必须支持分散应用组件之间的互操作性，而这必须采用分布式事务处理管理器。这是有别于传统的集中式事务处理的最鲜明的特点。指定一个事务叫做事务界定(demarcation)，通过把分布式的构件绑定到一个全局事务上来完成事务界定工作，它是标记构成一个事务的一组操作的一种方法。
最常用的界定的途径是为事务处理标记执行操作的线程，这叫做编程界定。这样建立的事务可以通过去除标记而被挂起，并在以后通过从挂起点向恢复点显式地传递事务上下文来恢复执行。 事务界定在向事务管理器的一个提交或一个回退请求之后结束，提交请求指导所有参与的资源管理器永久的记录事务中的操作的效果，回退请求使资源管理器撤消事务中所有操作的效果。
一个可替代编程界定的是声明界定。基于构件的事务处理系统如 Microsoft 事务服务器，以及基于应用服务器的事务处理系统如企业 Java Beans 规范支持声明界定。在这种技术中，构件在部署时被标记为事务性的。这暗示了两件事。首先，界定的职责从应用转移到了容纳构件的容器(Container)。为此，这种技术也叫做管理容器界定。其次，界定从应用建造期间(静态)延期到构件部署期间(动态)。
因为多个应用构件和资源参与了一个事务，对于事务管理器建立和维护发生的事务的状态是必须的。这通常以事务上下文的形式完成。 事务上下文是在资源上的事务性操作和调用操作的构件之间的一个关联(Association)。在一个事务执行期间，所有的参与事务的线程共享事务上下文。所以事务上下文在逻辑上封装(Envelop)了在一个事务期间在事务性资源上的完成的所有操作。事务上下文通常由底层的事务管理器透明的维护。讨论分布式事务的细节已经超出本书的范围，这里的目的是给大家一些思路和概念。下面分别介绍一下关于分布式事务处理的技术模型：
1. X/Open分布式事务处理模型
X/Open分布式事务处理(DTP)模型是Open Group提出的一个分布式处理模型，Open Group是一个厂商财团。这个模型是在事务处理和数据库领域中多数商业厂商间的一个标准。这个模型由四个构件组成：
(1) 应用程序：实现事务性操作
(2) 资源管理器：同于上面的讨论
(3) 事务管理器：同于上面的讨论
(4) 通信资源管理器：方便在不同的事务处理领域中的不同的事务管理器之间的互操作
X/Open DTP模型在产业界中被确立的。一些商业事务管理产品，像TXSeries/Encina (完全附属于IBM的Tranarc的产品)，Tuxedo和TopEnd (BEA Systems的产品)，还有 AT&T GIS 支持TX接口。尽管Microsoft的Transaction Server不支持TX接口，它还是能够同像Oracle这样的遵从XA的数据库互操作。类似的，多数商业数据库像Oracle，Sybase，Informix和 Microsoft SQL Server，以及消息中间件产品如IBM的MQSeries，和Microsoft的MSMQ Server 提供了XA接口的一个实现。
2. OMG对象事务服务
对象事务服务(OTS)是由对象管理组织(OMG)规定的分布式事务处理服务。这个规范扩展了CORBA模型并定义了一系列跨越(across)多个CORBA对象完成事务处理的接口。OTS模型基于X/Open DTP模型之上并提供增强，如OTS模型把函数形式的XA和TX接口替换成了CORBA IDL接口，在这个模型中的各种对象通过在IIOP之上的CORBA方法调用来通信。
OTS体系由下列构件组成：
事务客户：一个调用事务性对象上的操作的程序或对象。
事务性对象：一个封装(encapsulate)或参照(refers to)持久数据的 CORBA 对象，并且它的行为依赖于在一个事务期间是否调用它的操作。
可恢复对象：一个直接维护持久数据并且参与事务协议的事务性对象。
事务性服务器：一个或多个事务性对象的集合(collection)。
可恢复服务器：一个对象的集合，其中至少有一个是可恢复的。
资源对象：一个资源对象是为了参与两阶段提交和恢复协议而被注册的、在事务服务中的一个对象。