跟我学Hibernate框架技术——事务及特性和分布式事务实现实例(第1部分)

目录

1.1事务及特性和分布式事务实现实例（第1部分） (2)

1.1.1事务及事务的特性 (2)

1.1.2数据库的事务处理技术及应用实例 (7)

1.1.3基于数据库连接的事务处理技术及应用实例 (8)

1.1.4应用JDBC事务编程的实现实例 (10)

1.1.5使用事务处理服务器相关的技术 (16)

1.1事务及特性和分布式事务实现实例（第1部分）

1.1.1事务及事务的特性

1、事务及事务的特性

（1）事务概述

事务是一组原子操作（执行一组SQL）的工作单元，这个工作单元中的所有原子操作在执行期间，与其它事务隔离，以避免数据源的交相更新而发生混乱，事务中的所有原子操作，要嘛全部执行成功，要嘛全部失败（即使只有一个失败，所有的原子操作也要全部撤消）。（2）事务及事务的特性

在JDBC的数据库操作中，一项事务是由一条或是多条表达式所组成的一个不可分割的工作单元。事务具有原子性、隔离性等的ACID（代表不可分割性---atomicity、一致性---consistency、隔离性----isolation和稳定性----durability）。

●Atomic（原子性）：事务中包含的操作被看作一个逻辑单元，这个逻辑单元中的操作

要么全部成功，要么全部失败。

●Consistency（一致性）：只有合法的数据可以被写入数据库，否则事务应该将其回

滚到最初状态。

●Isolation（隔离性）：事务允许多个用户对同一个数据的并发访问，而不破坏数据

的正确性和完整性。同时，并行事务的修改必须与其他并行事务的修改相互独立。

●Durability（持久性）：事务结束后，事务处理的结果必须能够得到固化。

（3）应用示例：通过一个去银行从储蓄帐户转存500 美元到支票帐户的示例，可以帮助我们了解事务的ACID这四个特性的含意。

这里实际上发生了两个操作：首先，从储蓄帐户取出500 美元，然后将这500 美元存到您的支票帐户里。如果两个操作都成功，您和银行都会满意。如果两个操作都失败，您们也不必紧张，大家都可以接受这个结果，只要稍后再试一次就行了。

现在想象一下，如果在帐户转存操作过程中银行的计算机崩溃了，会发生什么情况？首先，假设银行计算机崩溃正好发生在从储蓄帐户中取出500 美元后，但在存入支票帐户之前。这样，您就会损失500 美元。

现在假设另外一种情况：如果在500 美元记入支票帐户后，但在从储蓄帐户中取出之前发生银行计算机崩溃，又会发生什么情况呢。您会很高兴，但银行是不会接受的。这两个操

作必需同时成功或同时失败------这就是原子性的定义。

在此例中，一致性的含义是指存入支票帐户的钱数应与从储蓄帐户中取出的钱数相等。借助于事务处理系统，一致性由应用程序逻辑来强制实施。

隔离性的含义是与帐户转存并发执行的单独事务不应看到无效的中间状态。在此例中，如果从储蓄帐户中取出500 美元，您永远看不到这500 美元尚未存到支票帐户的情况。隔离性通常用锁定来实现。

持久性的含义是在事务提交后，由事务进行的更新永远不会丢失。在事务提交之后，系统崩溃、网络故障，甚至有人不小心拔出了电源线都不应造成更新丢失。大多数数据库（以及其他类型的事务性资源）通过先将所有需要进行的更改写入持久存储的日记文件中，来确保持久性。只有在写入日记文件后，才会提交事务。如果在事务提交后系统崩溃或有人从插座中拔出电源插头，资源管理器会读取其日志并重试所有非永久性的已提交事务，或尝试回滚所有已中止的事务。

2、为什么要提供事务

（1）事务是一种手段，用于保证一系列的数据库操作能够准确的完成。

使用事务的一个重要原因，是完成一个操作可能需要使用多步，其中任何一步操作的失败，都希望全部回滚。以银行转账系统为例：

如下图所示，转账是通过两步完成的，但转账时，提款是正确的，但存款错误，总的账目将发生不平衡，显然这是不允许的。

（2）怎么解决这个问题呢?

我们可以把存款、提款、转账这三个商业对象注册到一个事务中去，当某个对象无法完成操作的时候，其它的对象自动恢复成原来的状态。

这个关系可以用下面的图来表示。

因此，事务机制对于一些关键事务是很重要的，例如ATM机提款，提款有多个动作：修改数据库以及数钱等，如果这其中有任何一个环节出错，那么其它已经实现的操作必须还原，否则，就会出现，提款人没有拿到钱，但是卡上已经扣款等不可思议的事情发生。

（3）事务处理的应用场合

这些应用在下列条件下应该维护数据的完整性(由应用的商务规则来定义):

●分布式访问一个单独的数据资源，以及

●从一个单独的应用构件访问分布式资源。

在这种情况，可能要求在(分布式)资源上的一组操作被当作一个工作单元(unit)。在一个工作单元中, 操作的所有部分一起成功或失败并恢复。

3、事务划分的基本原则

（1）原则一：使数据库访问的事务尽可能短小。

通过使事务尽量短小，您可以把阻碍其它事务的时间缩到最短，从而提高应用程序的可伸缩性。保持事务尽可能短小的最好方法当然是不在事务中间做任何不必要耗费时间的事，特别是不要在事务中间等待用户输入-----数据库长事务会导致你的应用程序无法扩展到高的并发负载。

因为事务提供并发控制，这通常意味着资源管理器将代表您获得您在事务期间访问的数据项的锁，并且它必须一直持有这些锁，直到事务结束（前面所讨论的 ACID特性，其中“ACID”的“I”代表“隔离”---Isolation，也就是说，一个事务的结果影响不到与该事务并发执行的其它事务）。

当您拥有锁时，任何需要访问您锁定的数据项的其它事务将不得不一直等待，直到您释放锁。如果您的事务很长，那些其它的所有事务都将被锁定，您的应用程序吞吐量将大幅度下降。

注意：通过对业务流中的对数据库访问进行优化来实现数据库访问的事务尽可能短小，在基于web的应用和企业应用中，跨用户交互的数据库事务是无法接受的。考虑下面的例子：在界面的第一屏，打开对话框，用户所看到的数据是被一个特定的 Session 和数据库事务载入(load)的。用户可以随意修改对话框中的数据对象。5分钟后，用户点击“保存”，期望所做出的修改被持久化；同时他也期望自己是唯一修改这个信息的人，不会出现修改冲突。

从用户的角度来看，我们把这个操作单元称为应用程序长事务（application transaction）。在我们的应用程序中，可以有很多种方法来实现它。

第一种比较简单的做法是，在用户思考的过程中，保持Session和数据库事务是打开的，保持数据库锁定，以阻止并发修改，从而保证数据库事务隔离级别和原子操作。这种方式当然是一个反模式，因为数据库锁定的维持会导致应用程序无法扩展并发用户的数目。

第二种必须使用多个数据库事务来实现一个应用程序事务，在这个例子中，维护业务处理流程的事务隔离变成了应用程序层的部分责任。单个应用程序事务通常跨越多个数据库事务。如果仅仅只有一个数据库事务（最后的那个事务）保存更新过的数据，而所有其他事务

只是单纯的读取数据（例如在一个跨越多个请求/响应周期的向导风格的对话框中），那么应用程序事务将保证其原子性。

（2）原则二：在事务期间不要等待用户输入

（3）原则三：把相关操作归到单个事务中，但把不相关的操作放到单独的事务中

根据前面的原则一中所要求的事务应尽可能短小，我们必须把一些操作归到一个事务中来维护一致性。

4、数据库操作过程中可能出现的三种不确定情况：

（1）脏读取（Dirty Reads）:一个事务读取了另一个并行事务未提交的数据。

如我们从数据库中读取了一个TUser对象：

Transaction tx=session.beginTransaction();

TUser user=(TUser)session.load(TUser.class,new Integer(1)); //此时user对象处于数据库读出的原始状态

user.setAge(30); //此时对象所携带的信息发生的变化，成为所谓的"脏数据"

https://www.360docs.net/doc/3d7318807.html,mit();

事务提交时，Hibernate会对session中的PO进行检测，判断那些发生了变化，并将发生变化的数据更新到数据库中。

这里就存在一个问题，Hibernate如何判断一个数据对象是否发生了变化，或者说，Hibernate如何进行脏数据识别? 脏数据检查的策略一般有两种：

●数据对象监控：数据对象监控的实现方式，基本上是通过拦截器对数据对象的设置方

法进行拦截，拦截器的实现可借助Dynamic Proxy或者CGlib实现。

一旦数据对象的设置方法被调用（通常这也意味着数据对象的内容发生变化），则将其标志为"待更新"状态，之后在数据库操作时将其更新到对象的库表中。

●数据版本比对：在持久层框架中数据对象的最近读取版本，当数据提交时将提交数据

与此版本进行比对，如果发生变化则将其同步到数据库相应的库表。

在Hibernate中采用的是第二种检查策略。

（2）不可重复读取（Non-repeatable Reads）

一个事务再次读取之前的数据时，得到的数据不一致，被另一个已提交的事务修改。（3）虚读（Phantom Reads）

一个事务重新执行一个查询，返回的记录中包含了因为其他最近提交的事务而产生的新

记录。

5、标准SQL规范中，为了避免上面3种情况的出现，定义了四个事务隔离等级：

（1）Read Uncommitted

最低等级的事务隔离，仅仅保证了读取过程中不会读取到非法数据。上诉3种不确定情况均有可能发生。

（2）Read Committed

大多数主流数据库的默认事务等级，保证了一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。

（3）Repeatable Read

保证了一个事务不会修改已经由另一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的情况，但是带来了更多的性能损失。

（4）Serializable

最高等级的事务隔离，上面3种不确定情况都将被规避。这个级别将模拟事务的串行执行。

1.1.2数据库的事务处理技术及应用实例

在实际的开发过程中，通常可以采用以下一些事务处理的方式：

●使用数据库的事务处理

●基于数据库连接的事务处理

●使用事务处理服务器

1、使用数据库的事务处理概述

一般的关系型数据库都提供了处理事务的能力，在数据库中，调用事务处理的一般流程是：

BEGIN TRANSACTION

--进行处理

如果在处理的过程中发生错误，ROLLBACK TRANSACTION

如果一切正常，COMMIT TRANSACTION

END TRANSACTION

2、示例代码

下面的代码演示了一个MS SQLServer的触发器中使用T-SQL进行事务处理的示例

CREATE TRIGGER TestTrig ON TestTab FOR UPDATE AS

BEGIN TRANSACTION

INSERT INTO TrigTarget

SELECT * FROM inserted

IF (@@error <> 0)

BEGIN

ROLLBACK TRANSACTION

END

ELSE BEGIN

COMMIT TRANSACTION

END

1.1.3基于数据库连接的事务处理技术及应用实例

1、基于数据库连接的事务处理概述

（1）各种数据库编成接口都提供了该特性

常用的数据库编成接口，如JDBC，ADO、https://www.360docs.net/doc/3d7318807.html,，都提供了基于数据连接进行事务处理的功能。

（2）编程实现其实并不复杂

使用基于连接的事务编程实现是很简单的-------只要指定事务边界，执行数据库代码，然后提交或者撤销事务就可以了。

2、JDBC中的事务特点：

（1）在JDBC中，打开一个连接对象Connection时，缺省是auto-commit模式也就是说，一条对数据库的更新表达式代表一项事务操作，操作成功后，系统将自动调用commit()来提交，否则将调用rollback()来回滚。

每个SQL语句都被当作一个事务，即每次执行一个语句，都会自动的得到事务确认。为了能将多个SQL语句组合成一个事务，要将auto-commit模式屏蔽掉。在auto-commit模式屏蔽掉之后，如果不调用commit()方法，SQL语句不会得到事务确认。在最近一次commit()方

法调用之后的所有SQL会在方法commit()调用时得到确认。

（2）在JDBC中，可以通过调用setAutoCommit(false)来禁止自动提交之后就可以把多个数据库操作的表达式作为一个事务，在操作完成后调用commit()来进行整体提交，倘若其中一个表达式操作失败，都不会执行到commit()，并且将产生响应的异常；此时就可以在异常捕获时调用rollback()进行回滚。

这样做可以保持多次更新操作后，相关数据的一致性

（3）示例代码如下

try

{

conn = DriverManager.getConnection("URL","username","userpwd");

conn.setAutoCommit(false);//禁止自动提交，设置回滚点

stmt = conn.createStatement();

stmt.executeUpdate(“alter table …”); //数据库更新操作1

stmt.executeUpdate(“insert into table …”); //数据库更新操作2

https://www.360docs.net/doc/3d7318807.html,mit(); //事务提交

conn.setAutoCommit(true);

}

catch(Exception ex)

{ ex.printStackTrace();

try

{

conn.rollback(); //操作不成功则回滚

}

catch(Exception e)

{

e.printStackTrace();

}

}

上述代码中的组件商务方法执行前，首先调用Connection对象实例con的setAutoCommit 方法并在方法中指定参数false，通知数据库服务器不自动提交SQL语句的执行结果。当组件中的方法执行成功后，调用con对象实例中的commit方法提交所有的数据库操作结果。在方法执行过程中如果发生任何类型的异常均导致事务范围内所有方法的运行结果回滚。（4）JDBC事务管理方式的实现机制

JDBC事务管理方式是通过数据库管理系统的事务管理器（Transaction Manager）实现的。在该方式中，通过java.sql.Connection对象中的connect方法界定出事务的起始位置后，与相关对应的数据库管理器将启动一个事务过程。

当组件方法运行结束后可以根据组件商务方法的运行情况调用commit方法向数据库提交运行结果或者调用rollback方法将事务范围内方法的运行结果回滚。

1.1.4应用JDBC事务编程的实现实例

1、创建数据库中的数据表和填入数据值

在教学示例的数据库文件stud.mdb中创建出两个数据库表，其各个字段的结构如下（1）FanTable1表中包含有三个字段

编号，int ,4字节，为主键

姓名，varchar，20字节

金额，money，8字节

（2）FanTable2表中包含有三个字段编号，int ,4字节，为主键

姓名，varchar，20字节

金额，money，8字节

（3）然后分别在该两表中输入数据

2、设计一个考虑JDBC事务的Java 应用程序---请见JDBC目录下的程序

执行该Java应用程序----注意JTAInJavaApp.java为main() 所在的程序

在转帐的金额中输入待转帐的数目，如5000，然后点击“从源到目标”按钮，将实现从表1向表2进行转帐并提示正确地转帐的提示。

当表1中的用户的金额不足的时候，如果再次进行转帐，将出现错误的提示文字并且没有向目标方进行转帐。

也可以点击“从目标到源”按钮，实现反转帐

设计原理

void sourceButton_actionPerformed(ActionEvent e)

{

boolean A=false;

boolean B=false;

try

{

conn=getConnection();

conn.setAutoCommit(false); //不考虑JDBC事务时，可以注释掉 stmt = conn.createStatement();

stmt.execute("select * from FanTable1 where 编号=" + sourceInputTextField.getText());

rs = stmt.getResultSet();

rs.next();

double transData=Double.parseDouble(transInputTextField.getText());

if (rs.getDouble("金额") >= transData)

{

stmt.executeUpdate("Update FanTable1 set 金额=金额-"+transInputTextField.getText()+" where 编号="+sourceInputTextField.getText());

A=true;

if (transData >= 0)

{

stmt.executeUpdate("Update FanTable2 set 金额=金额+"+transInputTextField.getText()+" where 编号="+targetInputTextField1.getText());

B=true;

}

if (A && B)

{

messageTextField.setText("转账正确");

https://www.360docs.net/doc/3d7318807.html,mit(); //事务有效，如果不考虑JDBC事务时，可以注释掉

}

else

{

messageTextField.setText("转账错误");

conn.rollback(); //不考虑JDBC事务时，可以注释掉

}

}

catch (Exception E)

{

E.printStackTrace();

}

finally

{

if (rs != null)

{

try

rs.close();

}

catch(Exception ignore)

{

}

}

if (stmt != null)

{

try

{

stmt.close();

}

catch(Exception ignore) {

}

}

if (conn != null)

{

try

{

conn.close();

}

catch(Exception ignore) {

}

}

displayAllData();

}

}

3、设计一个不考虑JDBC事务的Java 应用程序

（1）将原来的程序中的注释掉，也就是不需要JTA

（2）再次执行该程序

可以看出来，当发生转账错误的时候，转入方（目标）的数据还是继续增加，这就造成了数据的错误，这是不能允许的。

1.1.5使用事务处理服务器相关的技术

前面说明了使用数据库本身的事务处理，以及使用基于数据库连接的事务。但是，当我们的应用如果涉及到多个数据库事务的时候，前面的各种方式就力不从心了，特别是涉及到一些分布式处理的事务的时候，例如，在多个银行之间转帐。

在这种情况下，我们通常需要一个事务处理服务器来协调处理这些事务。下面说明如何实现对分布式事务的管理和实现、以及两阶段提交协议。

1、分布式事务

（1）什么是分布式事务

分布式事务就是事务分布在多个资源上、由多个组件共享的事务-----也就是一个涉及到多个独立资源管理器的事务。

（2）分布式事务具有如下的特征

●组件要在同一原子操作中与多个资源通信

在一个银行的系统中，资金可能从工商银行转帐到中国银行，这就涉及到两个银行系统。

●多个组件要在同一原子操作中操作

资金从工商银行转帐到中国银行的时候，要么转帐成功，双方的帐户的资金都发生变化，

要么失败，双方的帐户资金都没有变化，只有一方发生变化的情况是绝对不允许的。2、为什么需要分布式事务-----企业信息一般会分布在许多数据库中存储

大多数企业不会把他们所有的重要信息都存储在单个数据库中，在很多情形下，信息会分布在许多数据库中。

例如，一个网络零售商就可能有一个存储在公司办公室的Oracle 数据库中的客户帐户信息数据库，而订单执行信息可能会存储在合作伙伴公司仓库的SQL Server 数据库中。当一个客户向这个网络零售商订货时，该客户的帐户应记入公司办公室的数据库中，而订单记录应写入合作伙伴公司的SQL Server 数据库中。

如果总是要求客户支付产品的费用而从不发货，网络零售商的信誉就会受到损害。因此，为了防止这种情况的发生，更新应作为一个事务在这两个数据库中同时进行。如果任一个操作失败，每个资源管理器（数据库）都将回滚它的事务部分------这种类型的事务被称为分布式事务。

3、分布式事务要求

（1）分布式事务需要多个不同的事务管理器的合作

主事务管理器称为分布式事务管理器，与其他事务管理器协调。分布式事务管理器负责控制在若干本地事务管理器之间传递、分界和解析单个事务。本地事务管理器是参与分布式事务的事务管理器。

（2）需要提供XA的实现

数据库本身要支持XA，数据库的JDBC也要提供XA的实现（包括在JTA里面）。Oracle, Sybase, DB2, SQL Server等大型数据库才支持XA, 支持Global Transaction。

主要涉及javax.sql.XAConnection、javax.transaction.xa.Xid和javax.transaction.xa.XAResource。

4、分布式事务处理模型

（1）X/Open组织（即现在的Open Group）定义了分布式事务处理模型

X/Open DTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。

（2）X/Open 分布式事务（DTP）模型

一般而言常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM）是数据库，

常见的通信资源管理器（CRM）是消息中间件。

（3）各自之间的关系的图示

5、两阶段提交协议

通常情况下，事务管理服务器与数据库通过XA 接口规范，使用两阶段提交来完成一个全局事务，XA规范的基础是两阶段提交协议。

（1）在一次事务处理中需要访问多个数据库

企业应用程序往往需要访问不同数据源的数据，因此应用系统中的组件需要获得对多个资源管理器的多个连接。另一个需求可能是在一次事务处理中访问多个数据库。只有底层应用服务器支持在一次事务处理中使用两阶段提交协议访问多个JDBC 数据库时，才有可能实施该特性。

（2）实现分布式事务的关键就是两阶段提交协议

在此协议中，一个或多个资源管理器的活动均由一个称为事务协调器的单独软件组件来控制。

（3）两阶段提交协议的实现过程

在第一阶段

事务管理服务器请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给事务管理服务器一个同意提交的应答，此时数据库将不能再在该事务分支中加入任何操作，但此时数据库

并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态）。如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给事务管理服务器失败应答。

在第二阶段

事务管理服务器审查所有数据库返回的预提交结果，如所有数据库都可以提交，事务管理服务器将要求所有数据库做正式提交，这样该全局事务被提交。而如果有任一数据库预提交返回失败，事务管理服务器将要求所有其它数据库回滚其操作，这样该全局事务被回滚。（4）图示说明

下面的图显示事务成功（提交）

而下面的图显示由于某种原因，其中一个资源管理器无法提交时的两阶段提交协议。

以一个全局事务为例，AP首先通知事务管理服务器开始一个全局事务，事务管理服务器通过XA接口函数通知数据库开始事务，然后AP可以对数据库管理的资源进行操作，数据库系统记录事务对本地资源的所有操作。操作完成后事务管理服务器通过XA接口函数通知数据库操作完成。事务管理服务器负责记录AP操作过哪些数据库（事务分支）。AP根据情况通知事务管理服务器提交该全局事务，事务管理服务器会通过XA接口函数要求各个数据库做预提交，所有数据库返回成功后要求各个数据库做正式提交，此时一笔全局事务结束。

6、分布式事务处理模型的主要优点

XA规范对应用来说，最大好处在于事务的完整性由事务管理服务器和数据库通过XA接口控制，AP只需要关注与数据库的应用逻辑的处理，而无需过多关心事务的完整性，应用设计开发会简化很多。

7、在J2EE EJB组件的开发中使用分布式事务

（1）EJB容器为EJB组件提供了事务服务的支持

我们可以在EJB组件中使用Java 事务API（JTA）来访问事务服务，它提供对Java 事务服务（Java Transaction Service，JTS）的简单访问。

（2）J2EE 中支持XA 的两个资源类型：JDBC API和JMS API

对于任何遵循XA 规范的资源，JTA 的XA 部分都有能力协调用这些资源的事务（通过接口javax.transaction.xa.XAResource ）。

J2EE 中支持XA 的两个资源类型是JDBC API（通过接口javax.sql.XAConnection ）和JMS API（通过接口javax.jms.XAConnection ）。

8、在EJB组件中如何使用JTA的应用示例

（1）准备两个数据源

它们分别针对Oracle和DB2数据库，各自的JNDI分别为“jdbc/OracleXADS”和“jdbc/DB2XADS”。另外，还需要配置一个JMS 提供者，其JNDI名为“jms/XAExampleQ”。（2）设计和实现一个SessionBean组件

在该SessionBean组件中，提供一个方法。在该方法中实现以下三个功能：

●使用名为jdbc/OracleXADS 的数据源保持数据。

●使用名为jdbc/DB2XADS 的数据源保持数据。

●将JMS 消息中的数据发送到名为jms/XAExampleQ 的队列。

其代码示例如下

public void persistAndSend(String data) throws Exception

{

try

{

DataSource oracleDS = getDataSource("java:comp/env/jdbc/OracleXADS");

persist(data, oracleDS);

DataSource db2DS = getDataSource("java:comp/env/jdbc/DB2XADS");

persist(data, db2DS);

QueueConnectionFactory factory =