文件系统事务——仍然是一个棘手的领域吗？

过去，事务处理系统主要甚或完全依赖于数据库来处理那些要求事务性的 IO 行为的 ACID 各方面。无论库 / 框架、语言，或者文件系统级别，对文件系统操作事务的支持一直都很薄弱。最近，情况开始显示出改进的迹象。

虽然单独看某些文件系统操作（文件重命名、删除等），它们是原子的，但是到目前为止，很少有解决办法能够形成一组综合的 API，全方位地支持事务性的文件 IO 操作。如果文件操作（例如创建、修改、重命名、删除文件）需要作为事务的一部分而连贯地执行，那么应用程序往往必须依赖于自行设计的方案，去减少系统 / 应用失败或并发访问时出现不一致状态的可能性。

如果能使文件系统的事务支持更加健壮、全面，许多类型的应用都会受益：

• 办公软件（文字处理软件、电子制表软件等）——其中有大量的读、写、删除文件操作被执行
• 安装程序——如果发生失败或错误，这些软件可要求还原到最初的文件系统状态
• 不要求像 SQL 那么强大的搜索功能的应用——相较于数据库，如果这些应用把数据存储在简单文件（flat files）中，也许能更快
• 文档和内容管理系统——它们大量使用文件 IO 操作

在这个领域，最显著的一些发展成果有：

• 事务性 NTFS(TxF)——Windows 文件系统
• Commons Transaction——Apache Java 项目

在 MSDN Magazine 的一篇文章里，Jason Olson（微软的技术布道者）解释了TxF的主要特征，TxF 是一个将处理文件操作事务的设想引入到 Windows Vista 和下个 Windows Server 版本“Longhorn”的新特性。按照 Jason 的意思，TxF 的主要目标是：

提高应用稳定性；

事务性 NTFS 通过减少或消除应用中需要编写和维护的错误处理代码的数量，使应用获得更好的稳定性。这最终减少了应用的复杂度，并使应用更易于测试……没有事务性文件操作，要想防范每一个可能失败的场景几乎是不可能的，处理过程中的任何时刻操作系统都有可能失败。

提高平台稳定性：

……微软正在自己的产品中使用 TxF 来达到这一目标。目前 Windows Vista 和 Windows Server “Longhorn”中有三个核心的功能用到了事务性 NTFS：Windows 自动更新、系统还原、以及计划任务。它们都利用 TxF 在一个事务内往文件系统中写文件，以在出现任何异常（例如由于断电导致的系统重启）时能处理回滚 / 提交。

增加创新：

TxF 提供了一个不需要 SQL 调用就能使用事务的框架，这是对创新的推动。最终，事务性 NTFS 能根本改变开发人员编写应用程序的方式，让他们构建出更加健壮的代码。通过在设计里面结合事务，你编写代码的时候就不用时时防范每一个可能发生的失败。

由于 TxF 建立在内核事务管理器（Kernel Transaction Manager，KTM）之上，并且 KTM 能直接与 Microsoft 分布式事务协调器（Microsoft Distributed Transaction Coordinator）合作。Jason 描述到，事务性文件操作可以和其他使用 XA-Transactions 的技术并用，包括 SQL 操作、通过 WS-Atomic Transaction 或者 MSMQ 操作进行的 Web Service 调用——从而使文件系统也参与到 XA Transactions 之中。

Vista 和 Longhorn 的 Transactional Registry 中也实现了类似于 TxF 的设想。关于潜在性能影响，文章中也提到：“TxF 是严格的付费运转（pay-to-play）模式。如果你不使用处理事务性的文件操作，就不会有而外的代价”。他补充说，TxF 是为提交而优化的。

Apache 的Commons Transaction项目的目标之一是提供对文件系统的事务性访问，它的实现方式是与具体的文件系统提供者 / 实现无关的。这个 Java 库用一种悲观锁定方案来实现文件系统上的 ACID 事务。myjavatricks.com上的一篇博客介绍了Commons Transactions 的几个概念，以及以事务的方式执行基本文件操作的几个 Java 例子。

Commons Transaction 的核心组件是 FileResourceManager，FileResourceManager 创建事务、协调它掌管下的资源 / 文件的文件操作——复制、创建、删除、移动、写入，以及准备和提交事务。在初始化阶段要为 FileResourceManager 准备：

• 提交之后存放主要数据的目录
• 事务存储临时数据的目录（工作目录）
• 指示是否要对路径进行 URL 编码的布尔标记
• FileResourceManager 使用的日志器（logger）

启动之后，FileResourceManager 紧接着将试图回滚所有未完成的事务，除非事务在系统失败或者 FileResourceManager 遇到不可挽回的问题时已经在提交的过程中了，在这种情况下，FileResourceManager 会试图前滚事务。万一事务不能恢复，例如既不能回滚、也不能前滚，整个工作目录会由 FileResourceManger 标记为“脏”状态，在问题解决之前都不再允许对其进行修改。日志中的信息通常都可以帮助从“脏”状态进行手动恢复。

尽管 Commons Transaction 不能使一个文件系统变成符合 XA 的资源，但是在博客作者看来，如果你的应用程序需要文件系统事务，这个库“很可能比你自己能搞出来的任何自定义机制都要好”。

尽管要使文件系统中的事务达到与数据库相似的程度还有很长的一段路要走，但是至少已经有一些实现开始形成，并且打算在这个棘手的领域为开发者提供更切实可行的解决方案。