目录
1. Introduction to Berkeley DB Java Edition
1.1 Features(特点)
1.1.1 DPL Features (DPL 特点)
1.1.2 Base API Features (底层API特点)
1.1.3 Which API Should You Use? (你应该使用那种API?)
1.2 The JE Application
1.2.1 Database Environments
1.2.2 Key-Data Pairs
1.2.3 Storing Data
1.2.4 Duplicate Data
1.2.5 Replacing and Deleting Entries
1.2.6 Secondary Keys
1.2.7 Transactions 事务
1.2.8 JE Resources
1.2.9 Application Considerations
1.3 JE Backup and Restore
1.4 JCA Support
1.5 JConsole and JMX Support
1.6 Getting and Using JE
1.7 JE Exceptions
1.8 Six Things Everyone Should Know about JE Log Files
正文
1. Berkeley DB Java Edition 简介
欢迎来到Berkeley DB Java版（JE）。 JE是一个100％用Java编写的通用事务保护嵌入式数据库（JE不提供JNI调用）。因此，它为Java开发人员提供了对任意数据进行安全高效的进程内存储和管理。
您可以通过一系列Java API使用JE，这些API使您能够读取和写入数据，管理数据库并执行其他更高级的活动，例如管理事务。您用来与JE交互的Java API有两种基本的风格。第一个是高级API，可以让Java类持久化。第二个是较低级别的API，它在与JE数据库进行交互时提供了更多的灵活性。
注意
对于JE的长期用户来说，较低级别的API是您可能习惯使用的传统API。
无论您选择使用哪种API集，都有一系列在产品中通用的概念和API。本手册首先提供对JE的高级检查。然后描述您使用的API，而不管您选择使用的API集。然后它提供有关使用直接持久层（DPL）API的信息，以及有关使用更广泛的“基础”API的信息。最后，我们提供一些数据库管理信息。
请注意，此处提供的信息仅用于介绍API的使用情况。其他书籍描述更高级的主题，例如使用事务。有关JE文档集中其他标题的列表，请参阅“更多信息”部分。
1.1 Features(特点)
JE提供了一个企业级的基于Java的数据管理解决方案。您只需将一个jar文件添加到您的应用程序的类路径中即可。有关更多信息，请参阅获取和使用JE。
JE提供以下主要功能：
- 大型数据库支持。 JE数据库可以有效地从一个记录到数百万记录。 JE数据库的大小可能会受到硬件资源的限制，而不是JE对您施加的任何限制。
数据库在数据库中进行了描述。
- 数据库环境。数据库环境为一个或多个数据库提供了一个封装和管理单元。环境也是内部资源（如内存中缓存和后台线程）的管理单位。最后，您使用环境来管理并发和事务。请注意，所有使用JE的应用程序都需要使用数据库环境。
数据库环境在数据库环境中进行了描述。
- 多线程和进程支持。 JE是为多线程控制而设计的。读取和写入操作都可以由多个线程执行。 JE使用记录级锁定来实现线程应用程序中的高并发性。此外，JE使用超时检测死锁，以帮助您确保两个控制线程无限期地不死锁。
而且，JE允许多个进程访问相同的数据库。但是，在此配置中，JE要求不允许有多个进程写入数据库。保证只读进程在打开环境时保持一致，尽管存在可能过时的存储数据视图。
- 事务。事务允许您将一个或多个数据库上的一个或多个操作视为一个工作单元。 JE事务为数据库操作提供了应用程序开发人员的可恢复性，原子性和隔离性。
请注意，事务保护是可选的。交易在Berkeley DB，Java Edition Transaction Processing入门指南中有描述。
- 内存中缓存。通过避免不必要的磁盘I / O，高速缓存允许对读取和写入操作进行高速数据库访问。缓存将按需求增长至预先配置的最大大小。为了在启动时间后立即提高应用程序的性能，可以预加载缓存以避免数据生产请求的磁盘I / O。
高速缓存的大小描述了高速缓存管理。
- 索引。 JE可让您轻松创建和维护主要数据的二级索引。通过这种方式，您可以通过使用替代密钥或辅助密钥来快速访问数据。
指数如何工作取决于您使用的API。如果您正在使用DPL，请参阅使用索引。否则，请参阅辅助数据库。
- 日志文件。 JE数据库存储在环境目录中的一个或多个数字命名的日志文件中。日志文件是一次写入的，并且可以跨不同平台的平台移植。
与其他数据库实现不同，数据库文件（即“材料数据库”）和日志文件之间没有区别。 相反，JE使用基于日志的存储系统来保护数据库的修改。 在对数据库进行任何更改之前，JE会将有关更改的信息写入日志文件。
请注意，JE的日志文件与Berkeley DB的数据库文件不是二进制兼容的。 但是，这两种产品都提供转储和装载实用程序，并且这些操作的文件在各个产品线上都是兼容的。
备份和恢复Berkeley DB Java版应用程序中将更详细地介绍JE的日志文件。 有关使用JE的转储和加载实用程序的信息，请参阅命令行工具。 最后，在您学习JE时了解关于日志文件的简短列表，请参阅每个人都应该了解的关于JE日志文件的六件事。
- 后台线程。 JE提供了几个为您管理内部资源的线程。 检查指针负责将数据库数据刷新到作为事务提交结果写入缓存的磁盘（这是为了缩短恢复时间）。 压缩器线程删除数据库中因删除活动而为空的子树。 最后，清理线程负责清理和删除不需要的日志文件，从而帮助您节省磁盘空间。
后台线程管理在管理后台线程中描述。
- 备份还原。 JE的备份程序包括简单地将JE的日志文件复制到安全位置进行存储。 要从灾难性故障中恢复，请将存档的日志文件复制回磁盘上的生产位置，然后重新打开JE环境。
请注意，JE在打开数据库环境时始终执行正常恢复。 正常恢复根据数据库日志文件中找到的更改信息使数据库处于一致状态。
备份和恢复Berkeley DB Java版应用程序中介绍了JE的备份和恢复机制。
1.1.1 DPL Features(DPL特点)
DPL是JE提供的与JE数据库交互的两个API之一。 DPL提供了在不实现特殊接口的情况下使任何Java类型持久化的能力。 唯一真正的要求是每个持久化类都有一个默认的构造函数。
DPL提供了本章前面提到的所有功能。 此外，DPL为您提供：
一种安全，便捷的方式来访问持久对象。
不需要手动编码绑定。绑定是一种将数据类型转换为可存储在JE数据库中的格式的方法。如果您不使用DPL，则可能需要为您的数据类型创建自定义绑定。
有关创建数据绑定的更多信息，请参阅使用BIND API。
请注意，DPL API使用Java字节码增强来提供不使用Java反射的完全优化的绑定。
不需要外部模式来定义主索引键和辅助索引键。 Java注解用于定义所有元数据。
使用Java集合框架支持与外部组件的互操作性。任何索引都可以使用标准的java.util集合来访问。
类进化得到明确支持。这意味着您可以自动且透明地添加字段或扩展类型。
您还可以执行许多不兼容的类更改，例如重命名字段或重构单个类。这是通过使用称为突变的内置DPL机制完成的。在访问数据时会自动应用突变，以避免在软件升级期间宕机时间转换大型数据库。
持久化类字段可以是私有的，包私有的，受保护的或公共的。 DPL可以通过字节码增强或反射来访问持久性字段。
底层JE引擎的性能是安全防护的。所有DPL操作都直接映射到底层API，对象绑定是轻量级的，并且所有引擎调整参数都可用。
支持Java 1.5泛型类型和注释。
1.1.2 Base API Features(基础API特点)
如果您不使用DPL，那么您可能会对以下概念和功能感兴趣：
- 数据库记录。 所有数据库记录均按简单键/数据对组织。 密钥和数据都可以是从原始Java类型到最复杂的Java对象的任何内容。
数据库记录在数据库记录中描述。
直接数据库读取和写入。 您可以使用数据库对象的方法读取和写入数据库记录。 数据库记录中描述了使用数据库对象进行读写。
游标。 游标使您能够顺序移动数据库。 使用游标，您可以寻找数据库中的特定点（使用应用于数据库记录的键和/或数据部分的搜索条件），然后向前或向后退出数据库。
游标在使用游标中有详细描述。
JCA。 JE提供对Java连接器体系结构的支持。 有关更多信息，请参阅JCA支持。
JMX。 JE提供对Java管理扩展的支持。 有关更多信息，请参阅JConsole和JMX支持。
1.1.3 Which API Should You Use?(你应该使用哪一种API?
在JE提供给您的两个API中，我们建议您使用DPL，如果您只想让具有相对静态架构的类保持持久性。
此外，如果您正在Berkley DB和Berkeley DB Java Edition之间移植应用程序，则不应使用DPL，因为基本API与Berkley DB Java API非常接近。
此外，如果您的应用程序使用高度动态的模式，那么DPL对您的应用程序来说可能是一个糟糕的选择，尽管在这种情况下使用Java注解可以使DPL对您更好一些。
1.2 The JE Application(JE应用程序)
本节简要概述了构成JE应用程序的主要概念和操作。 本部分总结了您在与JE合作时需要做出的决定。
请注意，核心JE类都包含在com.sleepycat.je包中。 另外，本书描述了com.sleepycat.je.bind中的一些类。 绑定API用于转换Java对象进出字节数组。
1.2.1 Database Environments(数据库环境)
无论您使用的是何种JE API，您的数据都存储在数据库中。如果您使用DPL，则不直接管理这些数据库;相反，它们是由API管理的。另一方面，如果您使用较低级别的JE API，则必须直接管理数据库。这并不难，因为它主要涉及打开和关闭数据库，给它们命名等等。有关更多信息，请参阅数据库。
也就是说，JE总是要求你使用数据库环境。数据库环境为一个或多个数据库提供了一个封装单元。环境对应于磁盘上的目录位置，并且在其中您可以找到JE正在使用的所有文件。环境也用于管理JE资源，如交易。
要使用数据库环境，必须首先创建并打开它。为了创建数据库环境，它所在的目录位置必须已经存在。
通过实例化一个Environment对象来打开一个数据库环境。您的环境实例称为环境Handle(句柄)。
一旦你打开了一个环境，你用它来做什么取决于你的应用程序的性质;也就是说，您正在使用的JE API以及您是否使用高级功能（如事务）。 （有关使用事务的详细信息，请参阅Berkeley DB，Java Edition“事务处理入门”）。但是，至少在访问存储在JE中的数据之前，您必须始终打开您的环境。另外，在结束您的应用程序之前，您应该始终关闭您的环境。
数据库环境中对环境进行了更详细的描述。
1.2.2 Key-Data Pairs(键值对)
JE使用密钥数据对存储和检索数据。这个数据部分是你决定存储在JE中供未来检索的数据。关键是您想要用来查找存储的数据一旦放入JE数据库中的信息。
例如，如果您正在构建包含员工信息的数据库，那么数据部分就是您想要存储的关于员工的所有信息：姓名，地址，电话号码，物理位置，他们的经理等等。
但是，关键在于您查看任何特定员工的方式。如果您愿意，您可以有多个键，但数据库中的每个记录都必须有一个主键。如果您使用DPL，则此密钥必须是唯一的;也就是说，它不能在数据库中多次使用。但是，如果您使用的是基础API，那么这个要求就放宽了。有关更多信息，请参阅重复数据。
例如，就员工数据库而言，您可能会使用类似员工识别号码的主键作为主键，因为这可以唯一标识给定的员工。
您也可以选择在数据库中使用表示索引的辅助键。这些密钥对于给定记录不必是唯一的;事实上，他们往往不是。例如，您可以将员工的经理姓名设置为辅助键，以便找到给定经理的所有员工的工作。
1.2.3 Storing Data(存储数据)
根据您使用的API，您如何管理存储的信息有很大不同。 这两种API最终都在做同样的事情，但DPL隐藏了很多来自你的细节。
1.2.3.1 Storing Data in the DPL(在DPL中存储数据)
DPL用于将Java对象存储在底层的一系列数据库中。这些数据库使用EntityStore类对象进行访问。
要使用DPL，必须使用Java注解修饰要存储的类，以将它们标识为实体类或持久类。
实体类是具有主键和可选的一个或多个辅助键的类。也就是说，这些是您将使用DPL直接保存和检索的类。您使用@Entity java注释标识实体类。
持久化类是实体类使用的类。它们没有用于对象检索的主要或次要索引。而是在实体类直接使用它们时存储或检索它们。您使用@Persistent java注释标识持久化类。
一个对象的主键是从一个类的数据成员中获得的。您使用@PrimaryKey java注释标识哪个数据成员用作主键。
请注意，持久化类的所有非瞬态实例字段以及其超类和子类都是持久的。静态和瞬态字段不是持久的。类的持久字段可以是私有的，包私有的（默认访问），受保护的或公共的。
此外，简单的Java类型（如java.lang.String和java.util.Date）在实体类中使用时会自动作为持久类来处理;您不必做任何特殊的事情就可以将这些简单的Java对象存储在EntityStore中。
1.2.3.2 Storing Data using the Base API（底层API存储数据）
在不使用DPL时，记录键和记录数据必须是字节数组，并使用DatabaseEntry实例传递给JE并从JE返回。 DatabaseEntry仅支持Java字节数组的存储。必须使用Java序列化对复杂对象进行封送处理，或者对JE提供的绑定API进行更高效的封送
数据库记录和字节数组转换在数据库记录中描述。
通过调用数据库句柄上的put方法之一，将记录存储在数据库中。 JE使用任何可用的密钥和数据比较函数自动确定记录在数据库内部B-Tree中的正确位置。
您还可以使用数据库句柄检索或获取记录。获取是通过提供您想要检索的记录的关键字（有时也是数据）来执行的。
您还可以使用游标进行数据库放入和获取。游标本质上是一种可以迭代数据库记录的机制。像数据库和数据库环境一样，游标必须打开和关闭。游标使用Cursor类来管理。
数据库在数据库中进行了描述。游标在使用游标中有描述。
1.2.4 Duplicate Data（重复数据）
如果您使用的是基本API，则在创建时可以将数据库配置为允许重复数据。 请记住，JE数据库记录包含一个密钥/数据对。 那么，当两个或更多记录拥有相同的密钥但数据不同时，会发生重复的数据。 默认情况下，数据库不允许重复数据。
如果你的数据库包含重复的数据，那么只有一个简单的数据库基于一个键才会返回使用该键的第一条记录。 要访问该密钥的所有重复记录，您必须使用游标。
如果您使用DPL，则可以使用辅助键复制日期，但不能使用主键。 有关更多信息，请参阅检索多个对象。
1.2.5 Replacing and Deleting Entries（替换和删除实体对象）
如果您正在使用DPL，那么替换存储的实体对象只需检索它，更新它，然后再次存储它。要删除对象，请使用其主键或辅助键上可用的delete（）方法。如果使用辅助键上的delete（）方法，则该键所引用的所有对象也会被删除。请参阅删除实体对象以获取更多信息。
如果您使用的是基本API，那么如何替换数据库记录取决于数据库中是否允许重复的数据。
如果数据库中不允许重复的数据，那么只需使用适当的键调用Database.put（）将导致用新数据更新任何现有记录。同样，您可以通过向Database.delete（）方法提供适当的键来删除记录。
如果数据库中允许有重复数据，则必须将光标定位到要更新的记录上，然后使用光标执行put操作。
要使用基本API删除记录，可以使用Database.delete（）或Cursor.delete（）。如果数据库中不允许有重复数据，那么这两个方法的行为是相同的。但是，如果数据库中允许有重复项，则Database.delete（）将删除使用提供的键的每条记录，而Cursor.delete（）仅删除光标当前所在的记录。
1.2.6 Secondary Keys
辅助键提供了一种替代方式来定位存储在JE中的信息，而不是由主键提供的信息。 次要密钥通常指数据库中的多个记录。 通过这种方式，你可以找到所有绿色汽车（如果你正在维护一个汽车数据库）或所有棕色眼睛的人（如果你正在维护一个关于人的数据库）。 换句话说，辅助键表示数据的索引。
取决于您使用的是DPL还是基本API，创建和维护辅助键的方式有很大不同。
1.2.6.1 Using Secondaries with the DPL
在DPL下，通过使用@SecondaryKey注释声明特定字段为辅助键。 当你这样做时，你必须声明你正在创建什么样的索引。 例如，您可以声明一个辅助键成为ONE_TO_ONE索引的一部分，在这种情况下，该键对于该对象是唯一的。 或者您可以声明密钥为MANY_TO_ONE，在这种情况下，密钥可用于数据存储中的多个对象。
一旦确定了某个类的辅助键，就可以使用EntityStore.getSecondaryIndex（）方法访问这些键。
有关更多信息，请参阅声明二级索引。
1.2.6.2 Using Secondaries with the Base API.
在使用基本API时，可以使用称为辅助数据库的特殊类型的数据库创建和维护辅助键。在使用辅助数据库时，保存正在索引的数据的数据库称为主数据库。
您可以通过打开辅助数据库并将其与现有主数据库关联来创建辅助数据库。您还必须提供一个从主要记录生成辅助键（即索引）的类。无论何时添加或更改主数据库中的记录，JE都会使用此类来确定辅助键应该是什么。
当创建，修改或删除主记录时，JE会自动更新辅助数据库，以适合在主服务器上执行的操作。
您使用SecondaryDatabase类管理辅助数据库。您可以通过提供实现SecondaryKeyCreator接口的类的实例来确定如何为辅助数据库创建密钥。
辅助数据库在辅助数据库中进行了描述。
1.2.7 Transactions
事务处理为您的JE操作提供了高度的安全性，允许您管理一个或多个操作，就好像它们是单个工作单元一样。事务为您的JE操作提供可恢复性，原子性和隔离性。
事务通过允许JE撤销在应用程序或系统故障时可能正在进行的任何事务保护操作来提供可恢复性。
事务通过允许将许多操作分组为单个工作单元来提供原子性。要么所有的操作都成功，要么没有一个操作成功。这意味着如果一个写入操作因任何原因失败，则该事务中包含的所有其他写入操作也会失败。这确保了数据库从未部分更新，因为只有部分成功的读/写操作链。
事务通过确保事务永远不会写入正在使用（用于读取或写入）另一个事务的记录来提供隔离。同样，在交易结束之前，交易写入的任何记录都不能在交易之外读取。请注意，这只是默认行为;您可以配置数据库，光标或事务处理来放宽其隔离保证。
从本质上讲，事务隔离为事务提供了与数据库相同的未经修改的视图，即它在单线程应用程序中执行操作时会收到该视图。
事务可能很长或很短，它们可以包含尽可能多的操作，并且（如果使用基本API），只要所有参与的数据库都驻留在相同的环境中，它们就可以跨越数据库。
事务使用会导致应用程序的性能损失，因为它们通常需要比非事务操作更多的磁盘I / O。因此，虽然大多数应用程序将使用JE写入事务，但它们的使用是可选的。特别是，执行只读操作的进程可能不会使用事务。此外，使用JE进行轻松重新创建的缓存的应用程序也可能选择避免事务。
在您的JE应用程序中使用事务在Berkeley DB，Java Edition入门事务处理指南中有详细介绍。
1.2.8 JE Resources
JE有一些您可能想要管理的内部资源。其中最重要的是内存缓存。你应该仔细考虑JE缓存需要多大。如果将此数字设置得太低，JE将执行潜在的不必要的磁盘I / O，这将导致性能下降。如果将其设置得太高，那么您可能会浪费可以用于更好目的的RAM。
请注意，您为内存中缓存配置的大小是最大大小。在应用程序启动时，缓存开始非常小（仅为缓存最大允许大小的7％）。然后它随应用程序数据库操作的需要而增长。此外，缓存不会固定在内存中 - 它可以通过操作系统的虚拟内存系统分页。
除缓存之外，JE使用多个后台线程来清理JE日志文件，通过删除不需要的子树来压缩数据库，并将缓存中看到的数据库更改清除到后备数据文件。对于大多数JE应用程序来说，后台线程的默认行为应该是可以接受的，您不需要管理它们的行为。请注意，后台线程在环境打开时每个进程启动的次数不会超过一次。
有关调整缓存大小和后台线程大小的更多信息，请参阅管理Berkeley DB Java版应用程序。
1.2.9 Application Considerations
在构建JE应用程序时，一定要考虑以下几点：
你想存储什么数据？主键最适用的是什么？主要记录数据的最佳表示是什么？如果您使用的是基本API，请考虑将键和数据移入和移出字节数组的最有效方法。查看数据库记录了解更多信息。
数据的性质是否需要重复记录支持？请记住，只有在使用基本API时才能配置重复支持，然后才能在创建数据库时进行配置。请参阅打开数据库以获取更多信息。
如果您支持重复记录，则可能还需要考虑重复的比较器（而不仅仅是关键比较器）。有关更多信息，请参阅使用比较器。
你需要什么二级指标？如何根据存储在主数据库中的数据和密钥来计算二级索引？索引在辅助数据库中描述。
你需要什么样的缓存大小？有关如何调整缓存大小的信息，请参阅调整缓存大小。
您的应用程序是否需要事务（大多数情况）。事务在Berkeley DB，Java Edition Transaction Processing入门指南中有描述。
1.3 JE Backup and Restore
要备份数据库，请将日志文件（.jdb文件）从编号最低的日志文件开始，以最高编号的日志文件复制到备份介质。 请务必按照从最低到最高的顺序复制单个数据库文件的字节。 当您这样做时，您不必关闭数据库或停止数据库操作。
请注意，如果您使用子目录来存储日志文件，那么您应该复制这些子目录及其内容，而不是简单地复制单个文件。 可以使用多个子目录来提高JE吞吐量，但此功能默认情况下未打开。 有关如何配置此功能的信息，请参阅多环境子目录。
从备份还原JE数据库包括关闭JE环境，将归档的日志文件复制回环境目录，然后再次打开JE环境。如果您使用子目录来存储日志文件，请确保将这些子目录复制回环境主目录，并确保每个子目录中的日志文件与您执行备份时的相同。
请注意，无论何时打开JE环境，JE都会运行正常恢复。这涉及到在数据库中发现已更改的数据的情况下将数据库置于一致状态。如果您在正常操作期间使用事务，则JE将自动为您运行检查点，以限制运行此恢复所需的时间。在任何情况下，运行正常恢复都是例行操作，而执行数据库恢复不是。
有关JE备份和恢复以及检查点的更多信息，请参阅备份和恢复Berkeley DB Java Edition应用程序
1.4 JCA Support
JCA是Java连接器体系结构。 该体系结构为将J2EE平台连接到传统企业信息系统（EIS）（如ERP系统，数据库系统和未用Java编写的遗留应用程序）提供了标准。 JE支持这种架构。
想要在J2EE应用服务器中运行JE的用户可以使用JCA资源适配器通过标准API连接到JE。 请注意，如果您想要这样做，则需要基础API。 JE资源适配器支持所有三种J2EE应用程序服务器事务类型：
No transaction.（没有交易。）
Local transactions.(本地事务)
XA transactions.(XA事务)
JCA还包含Java Transaction API（JTA），这意味着JE支持2阶段提交（XA）。 因此，JE可以参与由J2EE服务器或直接使用JTA API的应用程序管理的分布式事务。
JE发行版包含一个在简单EJB中显示JCA使用情况的示例。 资源适配器已经使用JBoss 3.2.6和Sun Java System Application Server 8.1版进行了测试。 有关如何构建资源适配器以及为每个应用程序服务器运行简单的“Smoke Test”示例的说明，请访问：
JE_HOME/examples/jca/HOWTO-jboss.txt
and
JE_HOME/examples/jca/HOWTO-sjsas.txt
1.5 JConsole and JMX Support
JMX是Java管理扩展。 此扩展提供了用于管理和监视设备，应用程序和服务驱动型网络的工具。 JE支持这个扩展。
JE发行版提供了可在任何JMX服务器（例如J2EE应用程序服务器）中部署以监控JE环境的MBean。 可以从这些MBean调用统计信息和关键操作。 另外，JE为jconsole实用程序提供了一个插件，让用户以图形方式访问这些信息。
有关如何使用jconsole插件的信息，请参阅：
JE_HOME/docs/jconsole/JConsole-plugin.html
1.6 Getting and Using JE(开始使用JE)
您可以通过访问JE下载页面获取JE：http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index.html
要安装JE，请将分发包解压缩到您选择的目录。 如果您使用解压缩，请确保指定-U选项以保存大小写。
有关安装JE的更多信息，请参阅JE_HOME / docs / relnotes.html，其中JE_HOME是解压缩的JE的目录。
JE与Java SE 8（64位）兼容，并且已经针对Oracle Java SE 8和IBM Java IBM J9进行了测试和认证。 建议您升级到最新的Java版本，以利用最新的错误修复和性能改进。 JE下载中包含的版本说明指定了用于认证的确切Java版本。
Linux，Oracle Solaris和AIX是JE官方支持的平台。 支持Oracle Solaris x86和Oracle Solaris SPARC。 为了运行JE，需要64位JVM。
您可以通过将JE_HOME / lib / je- .jar添加到您的应用程序的类路径中来将JE用于您的应用程序。
除本手册外，您还可以在JE_HOME / docs / index.html目录中找到JE的文档。 具体来说，JE API集的完整Javadoc可在JE_HOME / docs / java / index.html中获得
1.7 JE Exceptions
在描述Java API用法之前，首先检查这些API抛出的异常是很有用的。 因此，本节简要介绍在编写JE应用程序时通常会遇到的异常。 这个清单不是确定性的。 根据您正在执行的特定数据库活动，可能会出现超出这些例外的情况。 有关更多信息，请参阅Javadoc。
所有的JE API都抛出DatabaseException。 DatabaseException扩展java.lang.Exception。 另外，以下类是DatabaseException的子类：
- DatabaseNotFoundException
在操作需要数据库时抛出，并且找不到该数据库。
- DiskLimitException
表示您已达到磁盘使用率阈值。超过这些阈值时不再允许写入。阈值使用EnvironmentConfig.MAX_DISK和EnvironmentConfig.FREE_DISK属性进行设置。任何写入操作（包括数据库记录写入，检查点以及数据库和环境同步）都会导致此异常。
关闭环境时，可以看到这个例外。但是，环境仍然会适当关闭。
有关设置这些属性的信息，请参阅设置磁盘阈值。
- EnvironmentFailureException
表示发生了可能会影响整个环境的故障。根据失败的性质，这个异常可能表明应该调用Environment.close（）。使用Environment.isValid（）来确定是否必须重新打开所有环境句柄。如果属实，环境可以继续运行而不会重新打开。
- LockConflictException
记录锁定冲突导致的所有异常的通用基类。收到此异常后，必须关闭任何打开的游标，封闭事务中止，并可选择重试事务。交易在Berkeley DB，Java Edition Transaction Processing入门指南中有描述。
- LogWriteException
写入JE日志时发生IOException或其他故障时抛出。这个异常可能表示磁盘已满，尽管IOException不包含足够的信息来确定此确定。
任何写入操作（包括数据库记录写入，检查点以及数据库和环境同步）都会导致此异常。
请注意，DatabaseException及其子类属于com.sleepycat.je包。
1.8 Six Things Everyone Should Know about JE Log Files
JE日志文件不像其他数据库系统的日志文件。 他们也不喜欢Berkeley DB C Edition创建的日志文件或数据库文件。 在本指南中，您将了解有关日志文件的更多信息，但在开始使用JE时请记住以下几点。
JE日志文件是“仅附加”。记录插入，删除和更新总是添加在当前文件的末尾。第一个文件被命名为00000000.jdb。当该文件增长到特定大小（默认为10 MB）时，名为00000001.jdb的新文件将成为当前文件，依此类推。
没有单独的数据库文件。与Berkeley DB C Edition不同，数据库不存储在独立于事务日志的文件中。事务日志和数据库记录一起存储在由多个日志文件组成的单个连续日志中。
JE清洁工负责回收未使用的磁盘空间。当日志文件中的记录被稍后日志文件中记录的删除或更新取代时，旧日志文件不再被充分利用。清理程序默认作为单独的线程运行，它决定最少使用的日志文件，将这些文件中仍然使用的记录复制到当前日志文件的末尾，最后删除现在完全未使用的日志文件。
有关吸尘器的更多信息，请参阅吸尘器螺纹。
清洁不立即开始，从不产生100％的利用率。在您编写了足够的数据来创建多个日志文件之前，通过删除和更新来删除某些数据，您将不会注意到清理程序将删除任何日志文件。默认情况下，清理在后台进行，并将日志文件维护在50％的利用率。您可以配置更高的利用率值，但配置过高的利用率值会降低整体性能。
关闭环境时不自动执行清洁。如果您希望在特定时间点将未使用的磁盘空间降至最低，则必须明确调用一种方法来执行日志清理。请参阅关闭数据库环境以获取更多信息。删除日志文件只发生在检查点之后。清理程序准备要删除的日志文件，但必须在检查点之后执行文件删除操作，以确保文件不再被引用。检查点按照自己的时间表进行，默认情况下每20 MB写入日志。这是在创建几个文件之后才会看到日志文件被删除的原因之一。
当使用JE的复制（高可用性）功能时，检查点不会删除已清理的日志文件，而是将文件的状态更改为保留。仅当磁盘利用率超过为EnvironmentConfig.MAX_DISK或EnvironmentConfig.FREE_DISK设置的值时，才会删除保留的文件。日志文件可以分布在多个目录中，因此可以通过链接或挂载点跨越多个磁盘。有关更多信息，请参阅多个环境子目录。