1.7. 关于事务服务质量

在选择实施您的交易系统的产品时，提供各种数据库产品和交易管理器，有些免费收费和一些商业系统。所有这些都不支持事务处理，但这些产品支持的服务质量有显著的差异。本节提供了比较不同交易产品的可靠性和复杂程度时需要考虑的功能的简单指南。

1.7.1. 由资源提供的服务质量

以下特性决定了资源的服务质量：

1.7.1.1. 事务隔离级别

ANSI SQL 定义四个 事务隔离级别，如下所示：

SERIALIZABLE: 事务完全相互隔离。也就是说，在提交事务前，一个事务都不会影响任何其他事务。这个隔离级别被描述为可序列的，因为其效果如同在所有事务都执行后执行，但实际上，资源通常会优化算法，以便允许一些事务同时进行。
REPEATABLE_READ: 每次事务读取或更新数据库时，都会获得读取或写入锁定，直到事务结束为止。这提供了几乎完美的隔离。但是，有一种情况是隔离并不完美。考虑使用 WHERE 子句读取行范围的 SQL SELECT 语句。如果在第一个事务运行时，另一个事务向这个范围添加一个行，则第一个事务可以查看这个新行（如果它重复 SELECT 调用( 读取)。
READ_COMMITTED: 在事务结束前，写入锁定会被保存。在事务结束前，读取锁定 不会被 保存。因此，重复读取可能会提供不同的结果，因为其他事务所提交的更新对持续事务可见。
READ_UNCOMMITTED: 在事务结束前，读取锁定或写锁都不会被保存。因此，脏读取是可能的。脏就绪是，当其他事务中未提交的更改对持续的事务可见。

数据库通常不支持所有不同的事务隔离级别。例如，一些可用的数据库只支持 READ_UNCOMMITTED。另外，一些数据库以与 ANSI 标准不同的方式实施事务隔离级别。隔离是一个复杂的问题，它涉及使用数据库性能权衡（例如，请参见 Wikipedia 中的隔离）。

1.7.1.2. 支持 XA 标准

要使资源参与涉及多个资源的事务，它需要支持 X/Open XA 标准。务必检查资源的 XA 标准的实现是否受到任何特殊限制的影响。例如，XA 标准的一些实现仅限于单个数据库连接，这意味着一次只有一个线程可以处理涉及该资源的事务。

1.7.2. 事务管理器提供的服务质量

以下功能决定了事务管理器的服务质量：

1.7.2.1. 支持 suspend/resume 和 attach/detach

有些事务管理器支持操作事务上下文和应用程序线程之间关联的高级功能，如下所示：

suspend /resume current transaction- 可让您临时暂停当前事务上下文，而应用在当前线程中执行一些非事务工作。
attach/detach transaction context- 可让您将事务上下文从一个线程移到另一个线程，或者扩展事务范围使其包含多个线程。

1.7.2.2. 支持多个资源

事务管理器的主要区别是能够支持多个资源。这通常支持 XA 标准，其中事务管理器为资源提供了注册其 XA 交换机的方法。

注意

严格说，XA 标准不是您可以用来支持多个资源的唯一方法，但它是最实际的一个。替代方案通常涉及编写繁琐（和关键）自定义代码，以实施通常由 XA 交换机提供的算法。

1.7.2.3. 分布式事务

有些事务管理器能够管理范围在分布式系统中包含多个节点的事务。通过使用特殊的协议（如 WS-AtomicTransactions 或 CORBA OTS）将事务上下文从节点传播到节点。

1.7.2.4. 事务监控

高级事务管理器通常提供可视化工具来监控待处理事务的状态。此类工具在系统失败后特别有用，它可以帮助识别和解决处于不确定状态（硬例外）的事务。

1.7.2.5. 从失败中恢复

在出现系统故障(crash)时，事务管理器与其稳健性相关的显著区别。事务管理器使用的关键策略是将数据写入持久日志，然后执行事务的每个步骤。如果出现故障，日志中的数据可用于恢复事务。一些交易经理会比其他人更仔细地实施此策略。例如，高端事务管理器通常会复制持久性事务日志，并允许每个日志存储在单独的主机机器上。