事务日志 —— 持久性的关键

事务 RM 通过在一个事务日志中记录多个事务的结果，获得持久性以及可接 受的性能。事务日志存储为连续的磁盘文件（有时存储在原始分区中），并且一 般只是用于写入而不用于读取，回滚或恢复的情况例外。在我们的银行账户示例 中，与账户 A 和账户 B 相关联的余额将在内存中进行更新，新的余额和旧的余 额将被写入到事务日志中。编写事务日志的更新记录不需要将全部数据都写入磁 盘（只需要写入已更改的数据，而不需要写入全部磁盘块），而且所需的磁盘寻 道时间也会更少（原因是所有更改都包含在日志中连续的磁盘块中）。此外，与 多个并发事务关联的更改可以合并到一起，一次写入事务日志，这意味着每次磁 盘写入时我们可以处理多个事务，而不需要每个事务进行几次磁盘写入。之后， RM 将根据所更改的数据更新实际的磁盘块。

重新启动时进行恢复

如果系统出现故障，重新启动时要做的第一件事就是重新应用所有已提交事 务的作用，所有这些已提交的事务都位于日志中，但是它们的数据块尚未更新。 采用这种方式，日志保证了故障之间的持久性，而且还能够减少所执行的磁盘 IO 操作的数量，或者至少使它们延迟到对系统性能影响更小的时间。

两阶段提交

很多事务只涉及一个 RM —— 通常是数据库。在这种情况下，RM 通常执行 提交或回滚事务所需的大部分工作。（几乎所有事务 RM 都有它们自己的内置的 事务管理器，这个管理器可以处理本地事务 —— 只涉及该 RM 的事务）。但是 ，如果事务涉及两个 RM 或多个 RM —— 可能是两个单独的数据库，或者是一 个数据库和一个 JMS 队列，或者是两个单独的 JMS 提供者 —— 我们想确保 “要么全有要么全无” 的语义不仅仅应用于这个 RM 中，而且还应用于事务中 的所有 RM。在这种情况下，TPM 将组织一个两阶段提交。在两阶段提交中，TPM 首先向每个 RM 发送一个 “准备” 消息，询问它是否准备就绪以及是否能够提 交事务；如果它收到来自所有 RM 的确认应答，则将事务在其自己的事务日志中 标记为已提交，然后指示所有 RM 提交事务。如果某个 RM 失败，则重新启动时 它将向 TPM 询问有关失败时未处理的所有事务的状态，并提交它们或者对它们 执行回滚操作。

两个阶段提交类似于社会上的结婚典礼 —— 牧师或神父询问双方 “您愿意 让这个男人/女人作为您的丈夫/妻子吗？” 如果双方都回答是，则将宣布他们 成为夫妻；否则，双方不能结婚。不管双方中的哪一方首先说 “我愿意”，在 一方没有回答时，另一方决不能完成结婚。

Java理论与实践: 理解JTS —— 事务简介(3)

事务作为处理异常的机制

您可能观察到，事务向对块进行同步的应用程序数据提供很多与内存中数据 相同的功能 —— 保证原子性、更改的可见性以及显而易见的排序。但是，当同 步主要是并发控制的机制时，则事务主要是处理异常的机制。如果在一个磁盘不 会发生故障、系统和软件不会崩溃以及电源是百分百可靠的世界中，我们将不需 要事务。事务在企业应用程序中所起的作用与合同法在社会上所起的作用一样 —— 它们规定，如果一方不能履行他那一部分合同，则交易将失效。当我们编 写合同时，我们通常希望它是多余的，令人感到欣慰的是大部分时候都是如此。

与比较简单的 Java 程

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!