翻译：寒蝉退士
[b]介绍[/b]
事务管理是对企业应用最紧要的要求之一。在贸易、金融和电子商业领域中，多数大的企业应用依赖于递送它们的商务的事务处理功能。 鉴于当今商务对灵活性的要求，在建造、部署和维护企业级别的分布式应用中，事务处理占据的是其中最复杂的部分之一。
本文把以下内容介绍给读者:
* 什么是事务? 什么是 ACID?
* 建造一个事务应用的要点是什么? 事务管理中间件为什么很重要?
* 事务处理应用的典型的体系是怎样的? 体系中的各种构件的职责是什么?
* 事务处理系统涉及哪些概念?
* 事务管理领域中有哪些标准和技术?
本文不特定于任何产品，力图在描述各种要点和概念时保持普遍性。本文不打算比较各种事务处理的技术/标准，只是提供对此的一个讨论。
[b]什么是事务?[/b]
为了完成对数据的操作，企业应用经常要求并发访问在多个构件之间共享的数据。这些应用在下列条件下应该维护数据的完整性(由应用的商务规则来定义):
* 分布式访问一个单独的数据资源，以及
* 从一个单独的应用构件访问分布式资源。
在这种情况，可能要求在(分布式)资源上的一组操作被当作一个工作单元(unit)。在一个工作单元中, 操作的所有部分一起成功或失败并恢复。在下面的情况下这个问题更加复杂:
* 通过一组分布式的、访问多个资源的数据的构件实现一个工作单元，和/或
* 部分操作是被顺序执行的或在要求协调和/或同步的并行线程中。
在所有情况下, 都要求应用维护一个工作单元的成功或失败。在失败的情况下，所有资源要把数据状态返回到以前的状态 (比如说，工作单元开始前的状态)。
事务的概念和和事务管理器(或者一个事务处理服务)在一个工作单元中的维护数据完整性，这就简化了这样的企业级别分布式应用的构造。
一个事务是有下列属性的一个工作单元:
* 原子性(ATOMICITY): 一个事务要被完全的无二义性的做完或撤消。在任何操作出现一个错误的情况下，构成事务的所有操作的效果必须被撤消，数据应被回滚到以前的状态。
* 一致性(CONSISTENCY): 一个事务应该保护所有定义在数据上的不变的属性(例如完整性约束)。在完成了一个成功的事务时，数据应处于一致的状态。换句话说，一个事务应该把系统从一个一致状态转换到另一个一致状态。举个例子，在关系数据库的情况下， 一个一致的事务将保护定义在数据上的所有完整性约束。
* 隔离性(ISOLATION): 在同一个环境中可能有多个事务并发执行，而每个事务都应表现为独立执行。串行的执行一系列事务的效果应该同于并发的执行它们。这要求两件事:
o 在一个事务执行过程中，数据的中间的(可能不一致)状态不应该被暴露给所有的其他事务。
o 两个并发的事务应该不能操作同一项数据。数据库管理系统通常使用锁来实现这个特征。
* 持久性(DURABILITY): 一个被完成的事务的效果应该是持久的。
这些属性叫做 ACID 属性，担保一个事务是永远不会不完整，数据永远不会不一致，并发事务是独立的，一个事务的效果是持久的。关于在分布式系统什么能出错的简要的一个描述，请参见 在事务处理系统中的容错和恢复。
[b]建造事务性应用的要点 [/b]
为了引出在建造事务性应用中涉及的要点，考虑一个定单获得和定单处理应用，它的体系在 图 1 中展示：
[img]http://dl.iteye.com/upload/attachment/231013/ccc4d051-518f-3705-9b66-83d38c83db35.gif[/img]
这个应用由两个客户构件组成，分别实现定单获得和定单处理操作。这两个操作构成了一个工作或事务单元。分别基于产品，定单，库存清单和货运信息。在这个图中，点断尖头指示的只读的数据访问，而连续尖头指示指示的是修改数据的事务性操作。下面是在这个应用中的事务性操作:
* 生成定单，
* 更新库存，
* 生成货运记录，并
* 更新定单状态。
当作为一个事务来实现这些操作时，应致力于下述要点:
1. 应用应当与事务性操作和被操作的数据库保持联系。所以应用应该为所有事务定义一个上下文来包含上述四个操作。
2. 因为定单获得和定单处理事务分布于两个构件之上，事务上下文应该是全局的，并通过协议的转换、被从第一个构件传播到第二个。
3. 当事务发生期间，应用应当监控事务的状态。
4. 为了维护事务的原子性，应用构件和/或数据库服务器、应当实现一种机制，在这种机制下对数据库的更改可以被撤消，而又不失去数据的一致性。
5. 为了隔离在共享数据上的并发的事务，数据库服务器应该跟踪被操作的数据，并在一个事务操作期间锁住数据。
6. 应用还应该维护数据库连接和事务之间的关联。
7. 为了实现可靠的锁定，应用构件应向数据库通知事务的终止
[b]介绍[/b]
事务管理是对企业应用最紧要的要求之一。在贸易、金融和电子商业领域中，多数大的企业应用依赖于递送它们的商务的事务处理功能。 鉴于当今商务对灵活性的要求，在建造、部署和维护企业级别的分布式应用中，事务处理占据的是其中最复杂的部分之一。
本文把以下内容介绍给读者:
* 什么是事务? 什么是 ACID?
* 建造一个事务应用的要点是什么? 事务管理中间件为什么很重要?
* 事务处理应用的典型的体系是怎样的? 体系中的各种构件的职责是什么?
* 事务处理系统涉及哪些概念?
* 事务管理领域中有哪些标准和技术?
本文不特定于任何产品，力图在描述各种要点和概念时保持普遍性。本文不打算比较各种事务处理的技术/标准，只是提供对此的一个讨论。
[b]什么是事务?[/b]
为了完成对数据的操作，企业应用经常要求并发访问在多个构件之间共享的数据。这些应用在下列条件下应该维护数据的完整性(由应用的商务规则来定义):
* 分布式访问一个单独的数据资源，以及
* 从一个单独的应用构件访问分布式资源。
在这种情况，可能要求在(分布式)资源上的一组操作被当作一个工作单元(unit)。在一个工作单元中, 操作的所有部分一起成功或失败并恢复。在下面的情况下这个问题更加复杂:
* 通过一组分布式的、访问多个资源的数据的构件实现一个工作单元，和/或
* 部分操作是被顺序执行的或在要求协调和/或同步的并行线程中。
在所有情况下, 都要求应用维护一个工作单元的成功或失败。在失败的情况下，所有资源要把数据状态返回到以前的状态 (比如说，工作单元开始前的状态)。
事务的概念和和事务管理器(或者一个事务处理服务)在一个工作单元中的维护数据完整性，这就简化了这样的企业级别分布式应用的构造。
一个事务是有下列属性的一个工作单元:
* 原子性(ATOMICITY): 一个事务要被完全的无二义性的做完或撤消。在任何操作出现一个错误的情况下，构成事务的所有操作的效果必须被撤消，数据应被回滚到以前的状态。
* 一致性(CONSISTENCY): 一个事务应该保护所有定义在数据上的不变的属性(例如完整性约束)。在完成了一个成功的事务时，数据应处于一致的状态。换句话说，一个事务应该把系统从一个一致状态转换到另一个一致状态。举个例子，在关系数据库的情况下， 一个一致的事务将保护定义在数据上的所有完整性约束。
* 隔离性(ISOLATION): 在同一个环境中可能有多个事务并发执行，而每个事务都应表现为独立执行。串行的执行一系列事务的效果应该同于并发的执行它们。这要求两件事:
o 在一个事务执行过程中，数据的中间的(可能不一致)状态不应该被暴露给所有的其他事务。
o 两个并发的事务应该不能操作同一项数据。数据库管理系统通常使用锁来实现这个特征。
* 持久性(DURABILITY): 一个被完成的事务的效果应该是持久的。
这些属性叫做 ACID 属性，担保一个事务是永远不会不完整，数据永远不会不一致，并发事务是独立的，一个事务的效果是持久的。关于在分布式系统什么能出错的简要的一个描述，请参见 在事务处理系统中的容错和恢复。
[b]建造事务性应用的要点 [/b]
为了引出在建造事务性应用中涉及的要点，考虑一个定单获得和定单处理应用，它的体系在 图 1 中展示：
[img]http://dl.iteye.com/upload/attachment/231013/ccc4d051-518f-3705-9b66-83d38c83db35.gif[/img]
这个应用由两个客户构件组成，分别实现定单获得和定单处理操作。这两个操作构成了一个工作或事务单元。分别基于产品，定单，库存清单和货运信息。在这个图中，点断尖头指示的只读的数据访问，而连续尖头指示指示的是修改数据的事务性操作。下面是在这个应用中的事务性操作:
* 生成定单，
* 更新库存，
* 生成货运记录，并
* 更新定单状态。
当作为一个事务来实现这些操作时，应致力于下述要点:
1. 应用应当与事务性操作和被操作的数据库保持联系。所以应用应该为所有事务定义一个上下文来包含上述四个操作。
2. 因为定单获得和定单处理事务分布于两个构件之上，事务上下文应该是全局的，并通过协议的转换、被从第一个构件传播到第二个。
3. 当事务发生期间，应用应当监控事务的状态。
4. 为了维护事务的原子性，应用构件和/或数据库服务器、应当实现一种机制，在这种机制下对数据库的更改可以被撤消，而又不失去数据的一致性。
5. 为了隔离在共享数据上的并发的事务，数据库服务器应该跟踪被操作的数据，并在一个事务操作期间锁住数据。
6. 应用还应该维护数据库连接和事务之间的关联。
7. 为了实现可靠的锁定，应用构件应向数据库通知事务的终止
