原子性日志操作
你可以将日志操作分为以下 3 类：

1. 不涉及事务原子性的日志操作。一个日志操作的失败不会导致整个事务的失败，并且即使在事务被中止的情况下日志操作仍旧可以成功。这类日志操作不需要消耗事务管理资源，也不需要日志服务支持事务
   
2. 可视为其它更新一样参与原子事务的日志操作。如果操作失败，整个事务过程需要回滚，并且只有在整个事务执行成功的前提下，日志操作才视为成功执行。
   
3. 半事务原子性的日志操作。只有当事务提交的时候日志操作才会成功，但日志操作的失败并不会导致事务被中止。在那种情况下，一些日志记录将会丢失，但日志存储并不会因为被中止的事务的记录而被“污染”。换句话说，并不存在脏写的记录。这种操作类型是在原子性和事务带来的巨大代价之间的折中。因为如果日志操作失败，并没有正常的事务操作受到影响，但如果事务失败，日志消息却会受到影响。

对于分布式计算来说， Web 服务是一个相对较新的消息基础设施。 Web 服务的事务性还没有得到相应的重视。最近， Web 服务组织就分布式事务如何与 Web 服务架构相协调提出 2 个草案 （商业事务和 Web 服务事务 -- 请参阅 参考资料）。这里我们不对这两个草案进行比较，相反，我们主要讨论 WS-Transaction 规范，因为它是一个更有发展前景的方案，但我希望你将这两个草案都阅读一下来形成你自己的观点。WS-Transaction 规范在分布式事务的参与者间定义了一个两阶段提交协议来支持事务原子性。

WS-Transaction
WS-Transaction 规范应用于基于 Web 服务的分布式系统。应用程序之间、应用程序与系统服务之间以及系统服务之间都是通过 Web 服务进行通信。规范以 Web 服务描述语言描述了原子性事务协议。协议内容如下：

• 完成： 应用利用此协议来初始化分布式事务提交循环。
  
• 两阶段提交： 首先参与分布式事务的应用程序必须延缓自身的更新。当完成指令被请求，一个协调器将向所有的事务参与应用程序发出一个 Prepare 消息。在接收到 Prepare 消息后，每个应用程序根据被延缓的更新是否可以提交来返回 Prepared 消息或 Aborted 消息。如果事务的所有参与者返回的都是 Prepare 消息，则它们将得到一个提交指令，这将导致所有的更新被提交，否则它们将得到一个放弃消息，所有被延缓的更新将被放弃。
  
• 阶段 0： 一旦一个两步提交循环开始，应用程序除了 Prepare 、Commit 和 Abort 指令外，不再执行任何操作。假设一个在缓存中包含若干更新的服务最终需要将更新存储到数据库中，那么它将需要调用一个数据库服务。由于应用程序在接收到 Prepare 指令后将禁止调用数据库服务，那么服务如何在 Commit 之前存储数据呢？这将通过阶段 0 协议来实现。在开始 Commit 循环之前，协调器将给参与者发送一个阶段 0 消息。
  
• 结果通知： 一些不属于分布式事务的应用程序仅仅想知道事务执行结果：提交还是放弃。它们可以通过结果同志协议获取这一信息。

WS-Transaction 规范建立在另外一个协议 WS-Coordination（请参阅 参考资料）之上. 上述 2 个协议都是以协议协调器和协议使用者之间的 Web 服务接口的形式来实现的。因此，存在必然存在两阶段提交协调服务和两阶段提交使用服务，阶段 0 协调服务和阶段 0 使用服务等等。这些协调服务和参与服务在 WS-Transaction 规范中通过 Web 服务描述语言（ WSDL）以端口类型的形式来描述。

事务支持的日志服务架构

图 5: 事务支持的日志服务架构

图 5 展示了一些参与节点和协议以及它们之间必要的交互。我们假定有 2 个应用程序节点（ Appl1 和 Appl2 ），一个数据库节点（ DB ），和一个包含日志服务的节点（ LogService ）。

节点及其服务

• Appl1 是一个初始应用程序，它希望完成分布式事务，因此它向协调器注册事务的完成协议。因此它将参与服务提供给完成协议（ P-C ）并使用协调器的服务来使用完成协议。它同样可以使用日志服务节点上的日志服务（ Logging ），发送不同事务原子级别的日志信息。另外，它还向节点 Appl2 发送应用程序信息，向数据库节点 DB 发送数据库请求。
  
• Appl2 被 Appl1 初始化并为 Appl1 工作。它在本地内存中缓存了许多更新，并希望最终将这些更新输送到数据库中，因此它通过协调器注册阶段 0 协议，因此必须将提供参与服务给阶段 0 协议 （ P-pz ）。
  
• DB 是数据库节点，它负责接收应用程序的更新，因此它作为一个参与者来注册两阶段提交协议。因此它必须提供参与服务（ P-2pc ）。
  
• LogService 是一个日志服务节点。它负责接收日志服务，每一个日志消息可能具有不同的事务原子级别。如果某个日志消息是事务原子性或半事务原子性，日志服务必须作为一个参与者来注册两阶段提交协议，这样她就必须提供参与服务给两阶段提交协议（ P-2pc ）。根据不同的缓存策略，它可能还需要注册阶段 0 协议来将日志消息存储到数据库中在事务完成之前。
  
• Coordinator 是一个 WS-transaction 协调节点，它提供如下协调服务：完成协议、阶段 0 协议、两阶段提交协议、C-c、 C-pz、 和 C-2pc。

消息顺序
由于篇幅限制，我们这里对参与者与协调器之间的协议注册消息不加讨论，你可以在 WS-Coordination 规范（参见 参考资料）中获取更多相关信息。在随后的讨论中，我们假定每一个节点对于它使用的协议都已经成功的注册了协调器。

必须说明的是，对于 WS-Transaction 定义的每一条消息，都同时还包含一个事务协调上下文。因为当消息通过 Web 服务环境传输时，事务协调上下文被包含在 SOAP 头中，规范中的上下文具有可扩展性，你可以通过一个代表日志消息所需的事务原子性级别的元素来对它进行扩展。这个指定的级别可以是空、半原子性和原子性。需要注意得是，任何消息都包含事务协调上下文，不管是应用程序间的消息还是应用程序发送给数据库的消息。

1. 应用程序与应用程序间存在消息，应用程序与数据库服务间存在消息，应用程序到日志服务间存在消息。每一个日志消息在事务协调上下文都包含指定的事务原子性级别信息。日志服务器总是检查这一信息。如果指定的级别是原子性或半原子性，日志服务不会将日志消息马上进行持续化处理，相反，它将这些日志信息保存在安全的地方，在提交过程中再将这些信息取回。如果事务原子性级别是空，日志消息将被立即写入永久性日志媒体中。
   
2. 节点 Appl1， 初始化应用程序，决定完成工作，因此调用协调器的完成服务 （C-c）。
   
3. 在初始化两阶段提交循环之前，协调器调用 Appl2 的阶段 0 参与服务。作为对此消息的响应， Appl2 通过数据库服务写入缓存的更新并将这一阶段 0 的成功报告给协调器。如果 Appl2 没能够完成阶段 0 ，协调器将会取消整个事务。
   
4. 如果阶段 0 成功，协调器将开始两阶段提交循环：
   • 协调器调用 LogService 和数据库服务器的 Prepare 操作。日志服务器检查日志服务是否准备好将所有事务原子性（不是半事务原子性）的日志消息持久化，如果检查失败，将向协调器报告 Abort 信息，否则报告 Prepared 信息。向协调器发送 Prepared 消息就好比作个可以提交的承诺，因此事务原子性的日志消息必须预先存储到稳定的存储器，这样 随后的提交即使日志服务在期间崩溃仍旧可以完成。
   • 如果每个参与者报告 Prepared，协调器将向每一个参与者发送 Commit 消息。然后日志服务器持久化所有事务原子性和半原子性的日志消息。如果持久化顺利完成，则向协调器报告 Commit。

协调上下文
在 WS-Transaction 规范中协调上下文被定义为一个事务相关的头信息的容器， 清单 1 给出了 SOAP 头中的协调上下文的结构。上下文结构包含一个元素 ， , 指定上下文的类型，它是一个 WS-Transaction URL。它说明这一协调器上下文包含一个 WS-Transaction 协议消息 。在上下文内部，我们引入新的元素 ， ，其中的命名空间是假定的，元素的值是日志信息指定的事务原子性级别，它可以是空、原子性或半原子性。

清单 1

 
. . . 
 
   2002-06-30T13:20:00.000-05:00  
  http://Fabrikam123.com/SS/1234
  
      http://schemas.xmlsoap.org/ws/2002/08/wstx 
  
   
  
      http://Business456.com/registration               
   
  ...
   
  semi-atomic 

... 

结束语
这篇文章指出日志是现代业务应用程序中的一个重要部分，需要像应用程序中其它的与业务相关的部分一样谨慎处理。如果业务需要日志作为企业及其处理流程的一部分，那么一个集中的日志服务便应需而生，因此日志 Web 服务是一个理想的选择。