第I部分 事务服务简述1. 事务综述事务是一个非常重要的编程概念，使用事务，可以很简单地构造出可靠稳定的应用程序，尤其对那些需要进行并发数据访问的应用程序，事务更是重要的多。事务的概念最初应用在那些用于商务操作的应用程序上，在这些应用中，事务用来保护中央数据库中的数据。随后，随着分布式计算的发展，事务在分布式计算领域中也得到了广泛的应用。现在，在分布式计算领域中，公认为事务是构造可靠性分布式应用程序的关键。
1.1事务产生的动机
1.1.1原子操作
考虑这样一个应用：用户把钱从一个银行账号转账至另一个银行账号，需要将资金从一个银行账号中取出，然后再存入另一个银行账号中。理想来说，这两次操作都应该成功。但是，如果有错误发生，则两次操作都应该失败，否则的话，操作之后其中一个账号中的金额将会是错误的，整个操作过程应该是原子性的，两个操作都是一个原子事务操作的一部分。
可以使用异常处理来处理上述问题，代码如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| try{
//从账户1中取款
}
catch(Exception e){
//如果发生错误，则终止操作
return;
}
try {
//如果第一步没有发生错误，则将提取出的资金存入账户2
}
catch(Exception e) {
//如果发生错误，则终止这步操作，并且将从账户1中取出的资金再重新存回到账户1中
return ;
}
|
上面这种解决方法从存在着下面的问题：
- 程序拖沓冗长
- 必须考虑到每一步中可能发生的每一个问题，并且要编写错误处理程序来考虑如何撤销所作的操作
- 如果执行的是比简单的取款、存款操作要复杂的多的程序，那么错误处理程序将会变得难以控制。
- 编写测试程序将会非常困难
因此，需要一种事务处理机制来保证这种原子性的操作。
1.1.2 网络故障或机器故障
为了在发生严重故障之后，能够保证系统的状态是一致的，所以需要一种恢复性的机制来保证这一点。
1.1.3 数据共享
需要一种机制来保证多用户并发访问数据的问题。
以上这些问题的解决方法，便是使用事务服务。
1.2 使用事务服务带来的好处
使用事务，便可以利用事务的四个重要属性：ACID。
- 原子性( atomic)：事务中包含的各项操作必须全部成功执行或者全部不执行。任何一项操作失败，将导致整个事务失败，其他已经执行的任务所作的数据操作都将被撤销，只有所有的操作全部成功，整个事务才算是成功完成。
- 一致性( consistent)：保证了当事务结束后，系统状态是一致的。那么什么是一致的系统状态？例如，如果银行始终遵循着"银行账号必须保持正态平衡"的原则，那么银行系统的状态就是一致的。上面的转账例子中，在取钱的过程中，账户会出现负态平衡，在事务结束之后，系统又回到一致的状态。这样，系统的状态对于客户来说，始终是一致的。
- 隔离性( isolated)：使得并发执行的事务，彼此无法看到对方的中间状态。保证了并发执行的事务顺序执行，而不会导致系统状态不一致。
- 持久性( durable)：保证了事务完成后所作的改动都会被持久化，即使是发生灾难性的失败。可恢复性资源保存了一份事务日志，如果资源发生故障，可以通过日志来将数据重建起来。
2. 事务应用事务服务支持的应用由下列实体组成：
- 事务客户(TC,Transactional Client)
- 事务对象(TO,Transactional Objects)
- 可恢复对象(Recoverable Objects)
- 提供事务支持的服务器(Transactional Servers)
- 可恢复资源服务器(Recoverable Servers)
下图展示了一个简单的事务应用，包含了基本的事务元素：
 - 事务客户：事务客户是一个独立的程序，调用参与事务的多个事务对象。发起事务的程序被称为事务发起者(Transaction Originator)。
- 事务对象：指那些在事务范围内行为会被影响的对象。事务对象自身包含了对持久化数据的操作或者通过事务请求间接对持久化数据进行操作。事务服务并不要求所有的事务请求都具有事务性的行为。与事务对象相对的是非事务对象。
- 可恢复对象(Recoverable Objects)和资源对象(Resource Objects)：如果事务提交和事务的回滚将影响某个对象里面的数据，那么这个对象称为一个可恢复对象。一个对象可以是事务对象而不是可恢复对象，因为事务对象可以使用其他的可恢复对象。可恢复对象必须将自己注册为事务服务中的一个资源对象，才可以参与到事务中。
- 支持事务的服务器：例如应用服务器
- 可恢复服务器：例如数据库
3. 事务服务提供的功能事务服务提供下列操作：
- 控制事务的范围和持续时间
- 让多个对象参与到一个单独的原子性事务中
- 将对象内部状态的改变同事务相联系
- 协调事务完成
3.1事务模型
- 平面型事务模型整个事务是一个整体，不可划分为子事务。
- 嵌套式事务模型嵌套有子事务，子事务中还可以嵌套有子事务，整个是一个树形结构。旅行计划问题：
- 购买从美国波士顿到美国纽约的火车票
- 购买从美国纽约到英国伦敦的飞机票
- 购买从英国伦敦到法国巴黎的气艇票
- 发现没有飞往法国巴黎的气艇票
这对于平面型事务来说，只能有一个选择：事务失败。这样由于没有飞往巴黎的气艇票，将会取消所有的出行计划。但是在这里，完全可以采用其他的旅行方式(购买火车票或者飞机票)来代替气艇。因此需要一个更加健壮的事务模型来解决这个问题。可以将整个事务划分为若干个子事务，整个事务可以重新执行单个子事务来尝试完成事务，如果最终某个单个子事务无法完成，则整个事务失败。 - 其他事务模型
锁链式模型、传奇式模型等。
3.2 事务的终止
通过发出提交请求或回滚请求来终止事务。通常，事务是由发起事务的客户(事务发起者)来终止的。
3.3事务的完整性
某些事务服务的实现为了保证事务的完整性，在事务服务接口的使用上施加了一些限制。这称为checked事务行为。例如，在事务的所有任务完成之前提交事务会导致数据不完整。事务服务的Checked实现会阻止事务的过早提交。其他事务服务的实现则完全依赖应用程序来提供事务的完整性保证，这称为unchecked事务行为。
3.4事务的上下文
事务上下文惟一标识了一个事务,保存了事务的当前状态。通过查询事务上下文，可以得知自身是否处于事务中，所在事务的状态以及其他一些有用的信息。
事务上下文可以作为事务操作调用的一部分隐式地传递给事务对象。事务服务也允许程序员将事务上下文作为事务请求的显示参数来传递。
4. 分布式事务分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。为了实现分布式事务，需要使用下面将介绍的两阶段提交协议。
- 阶段一：开始向事务涉及到的全部资源发送提交前信息。此时，事务涉及到的资源还有最后一次机会来异常结束事务。如果任意一个资源决定异常结束事务，则整个事务取消，不会进行资源的更新。否则，事务将正常执行，除非发生灾难性的失败。为了防止会发生灾难性的失败，所有资源的更新都会写入到日志中。这些日志是永久性的，因此，这些日志会幸免遇难并且在失败之后可以重新对所有资源进行更新。
- 阶段二：只在阶段一没有异常结束的时候才会发生。此时，所有能被定位和单独控制的资源管理器都将开始执行真正的数据更新。
在分布式事务两阶段提交协议中，有一个主事务管理器负责充当分布式事务协调器的角色。事务协调器负责整个事务并使之与网络中的其他事务管理器协同工作。
 为了实现分布式事务，必须使用一种协议在分布式事务的各个参与者之间传递事务上下文信息，IIOP便是这种协议。这就要求不同开发商开发的事务参与者必须支持一种标准协议，才能实现分布式的事务。
以上从事务整体描述的角度简要介绍了事务服务产生的动机、事务服务的应用和事务服务的功能，下面以J2EE中的事务服务为例对事务的实现作简要的介绍。 |
