1. 介绍
本书提供了与Berkeley DB，Java Edition（JE）一起使用的事务的全面介绍和讨论。 本手册中使用了基本API和直接持久层（DPL）API。 首先概述了事务，它们提供的保证以及为数据获取完整事务保护所需的一般应用程序基础结构。
本书还提供了有关如何编写事务性应用程序的详细示例。 讨论了单线程和多线程。 本手册中包含各种备份和恢复策略的详细说明，以及有关事务性应用程序的性能注意事项的讨论。
在阅读本书之前，您应该了解Berkeley DB入门指南中的概念。
1.1 Transaction Benefits 事务好处
事务为应用程序或系统故障提供应用程序的数据保护。 也就是说，JE交易为您的应用程序提供完整的ACID支持：
- Atomicity 原子性
多个数据库操作被视为单个工作单元。一旦提交，在事务保护下执行的所有写操作都将保存到您的数据库中。此外，如果您中止事务，则会丢弃在事务期间执行的所有写入操作。在这种情况下，无论您在交易过程中执行的写入操作的数量或类型如何，您的数据库都将处于事务开始之前的状态。
请注意，JE事务可以跨越一个或多个数据库句柄。
- Consistency 一致性
您的数据库永远不会看到部分完成的事务。即使您的应用程序在正在进行的事务中失败，也是如此。如果应用程序或系统出现故障，则在下次运行应用程序时会显示所有数据库更改，或者不显示任何数据库更改。
换句话说，无论您的应用程序具有何种一致性要求，JE都不会违反。例如，如果您的应用程序要求每条记录都包含一个员工ID，并且您的代码忠实地将该ID添加到其数据库记录中，那么JE将永远不会违反该一致性要求。 ID将保留在数据库记录中，直到您的应用程序选择删除它为止。
- Isolation 隔离性
当事务正在进行时，您的数据库将在事务中显示，就好像在事务之外没有其他操作发生一样。也就是说，包含在事务中的操作将始终具有干净且一致的数据库视图。他们永远不必在另一个交易的保护下看到当前正在进行的更新。但请注意，可以从默认设置增加和放宽隔离保证。有关更多信息，请参阅隔离。
- Durability 持久性
一旦提交到您的数据库，即使应用程序或系统出现故障，您的修改也会持续存在。请注意，与隔离一样，您的耐用性保证可以放宽。有关详细信息，请参阅非持久性事务。
1.2 A Note on System Failure
本手册有时会提到交易可以保护您的数据免受“系统或应用程序故障”的影响。这在某种程度上是正确的。但是，并非所有故障都是平等的，并且没有任何数据保护机制可以保护您免受计算系统发现死亡的所有可能方式的影响。
通常，当本书讨论防止故障时，这意味着事务可以防止系统和应用程序崩溃的最可能的罪魁祸首。只要您的数据修改已提交到磁盘，即使您的应用程序或操作系统随后失败，这些修改也应该保留。而且，即使应用程序或操作系统在事务提交（或中止）过程中失败，磁盘上的数据也应处于一致状态，或者应该有足够的数据可用于使数据库处于一致状态（通过例如，恢复程序。但是，您可能会丢失在发生故障时提交的任何数据，但您的数据库将不会受到影响。
请注意，许多磁盘都有磁盘写入缓存，并且在某些系统上默认启用它。 这意味着事务可以已提交，并且对于您的应用程序，数据可能看起来驻留在磁盘上，但实际上数据可能仅驻留在写入缓存中。 这意味着如果启用了磁盘写入缓存并且没有备用电池备份，则即使在使用最大持久性模式时，操作系统崩溃后数据也可能会丢失。 为获得最大耐用性，请禁用磁盘写入缓存或使用带备用电池的磁盘写入缓存。
当然，如果您的磁盘出现故障，那么本书中描述的事务优势与您所执行的备份一样好。
最后，通过遵循本书中显示的编程示例，您可以编写代码，以便在代码崩溃时保护您的数据。 但是，没有编程API可以保护您免受自己代码中的逻辑故障的影响; 事务不能保护您不要简单地将错误的东西写入您的数据库
1.3 Application Requirements 应用程序需要
为了使用事务，您的应用程序具有超出非事务性受保护应用程序所需的某些要求。他们是：
- Transaction subsystem.交易子系统。
要使用事务，必须为应用程序显式启用事务子系统，这必须在首次创建环境时完成。
- Transaction handles. 交易处理。
为了获得事务子系统提供的原子性保证（即，在单个工作单元中组合多个操作），您的应用程序必须使用事务句柄。这些句柄是从您的Environment对象获得的。它们通常应该是短暂的，并且它们的使用相当简单。要完成事务并保存它执行的工作，请调用其commit（）方法。要完成事务并放弃其工作，请调用其abort（）方法。
此外，如果要事务保护单个写操作，则可以使用自动提交。自动提交允许在不获取显式事务句柄的情况下使用事务。有关如何使用自动提交的信息，请参阅自动提交。
- Entity Store 实体存储
如果您正在使用DPL，则必须在打开实体存储之前配置实体存储以获取事务支持（即，在首次从它们获取主索引之前）。
- Database open requirements. 数据库打开需要。
如果要对数据库的后续操作进行事务保护，则应用程序必须事务保护数据库打开，以及任何辅助索引关联。数据库开放和二级索引关联通常使用自动提交进行事务保护。
- Deadlock detection.死锁检测。
通常，事务性应用程序在访问数据库时使用多个控制线程。每当在单个资源上使用多个线程时，就会出现锁争用的可能性。反过来，锁争用可能导致死锁。有关更多信息，请参阅锁，块和死锁。
因此，事务性应用程序必须经常包含用于检测和响应死锁的代码。请注意，此要求并非特定于事务 - 您当然可以编写并发的非事务性JE应用程序。此外，并非每个事务性应用程序都使用并发性，因此并非每个事务性应用程序都必须管理死锁。尽管如此，死锁管理仍然是交易应用程序的一个特征，我们将在本书中对其进行讨论。有关更多信息，请参阅并发。
1.4 Multi-threaded Applications 多线程应用程序
JE旨在支持多线程应用程序，但它们的使用意味着您必须特别注意并发问题。事务通过为您的控制线程提供各种级别的隔离来帮助您的应用程序的并发性。此外，JE提供了允许您检测和响应死锁的机制。
隔离意味着一个事务所做的数据库修改通常不会被另一个事务的读者看到，直到第一个事务提交更改为止。不同的线程使用不同的事务句柄，因此该机制通常用于提供由不同线程执行的数据库操作之间的隔离。
请注意，JE支持不同的隔离级别。例如，您可以将应用程序配置为查看未提交的读取，这意味着一个事务可以查看已修改但尚未由另一个事务提交的数据。这样做可能意味着您的事务会读取另一个事务“脏”的数据，但随后可能会在其他事务提交更改之前更改。另一方面，降低隔离要求意味着您的应用程序可以通过减少锁争用来提高吞吐量。
有关并发性，管理隔离级别和死锁检测的更多信息，请参阅并发。
1.5 Recoverability 可恢复
JE的交易保证的一个重要部分是耐久性。持久性意味着一旦提交了事务，在其保护下执行的数据库修改将不会因系统故障而丢失。
JE支持针对日志文件子集运行的正常恢复。这是在应用程序启动时首次打开环境时使用的常规过程，旨在确保数据库处于一致状态。 JE还支持在灾难性故障情况下的归档备份和恢复，例如丢失物理磁盘驱动器。
本书介绍了可用于保护磁盘数据的几种不同备份过程。这些过程包括简单的脱机备份策略和热故障转移。热故障转移不仅提供备份机制，还提供从致命硬件故障中恢复的方法。
本书还介绍了您应该使用的每种备份策略的恢复过程。
有关备份和还原过程的详细说明，请参阅“Berkeley DB入门”，Java版指南。
1.6 Performance Tuning 性能调优
从性能角度来看，交易的使用并不是免费的。 根据您的配置方式，事务提交通常要求您的应用程序执行非事务性应用程序不执行的磁盘I / O. 此外，对于多线程应用程序，由于事务隔离保证驱动的额外锁定要求，事务的使用可能导致锁争用增加。
因此，事务性应用程序的性能调整组件不适用于非事务性应用程序（尽管某些调优注意事项确实存在，无论您的应用程序是否使用事务）。 在适当的情况下，以下章节将介绍这些调整注意事项。