New major release, JE 5.0, is available

Question

Hi all,
We're pleased to announce a new major release, JE 5.0.34. The release contains a significant number of new features and performance enhancements. Complete information can be found in the JE documentation, specifically in the change log. The release is available via the download site or Maven.
Below is a copy of the major enhancements listed in the release notes. See the change log for a complete list.
<li> The new DiskOrderedCursor class can be used to iterate over all records in a database, for increased performance when transactional guarantees are not required. [#15260]
<li> A new Environment.preload method can be used to preload multiple databases at a time, for increased performance compared to preloading each database individually. [#18153]
<li> The JE environment can now be spread across multiple subdirectories to take advantage of multiple disks or file systems. [#19125]
<li> The new AppStateMonitor class lets the HA application add more application specific information to the notion of node state in a replication group. [#18046]
<li> New options have been added for changing the host of a JE replication node, and for moving a JE replication group. See the Utilities section of the change log.
<li> Replicated nodes can now be opened in UNKNOWN state, to support read only operations in a replicated system when a master is not available. [#19338]
<li> New Cursor methods were added to allow quickly skipping over a specified number of key/value pairs. [#19165]
<li> A per-Environment ClassLoader may now be configured and will be used by JE for loading all user-supplied classes. [#18368]
<li> The java.io.Closeable interface is now implemented by all JE classes and interfaces with a public void close() method. This allows using these objects with the Java 1.7 try-with-resources statement. [#20559]
<li> The Environment.flushLog method has been added. It can be used to make durable, by writing to the log, all preceding non-transactional write operations, without performing a checkpoint. [#19111]
<li> Performance of record update and deletion operations has been significantly improved when the record is not in the JE cache and the application does not need to read the record prior to performing the update or deletion. [#18633]
<li> An internal format change was made for databases with duplicate keys that improves operation performance, reduces memory and disk overhead, and increases concurrency. [#19165]
<li> An improvement has been made that requires significantly less writing per checkpoint, less writing during eviction, and less metadata overhead in the JE on-disk log files. [#19671]
<li> Improved DbCacheSize utility to take into account memory management enhancements and improve accuracy. Added support for key prefixing, databases configured for sorted duplicates, and replicated environments. [#20145]
<li> EnvironmentConfig.TREE_COMPACT_MAX_KEY_LENGTH was added for user configuration of the in-memory compaction of keys in the Btree. [#20120]
-- The JE Team

Answer 1

The format change is for BDB Java Edition 5.0 only, and does not apply to other BDB products. It's forward compatible, which means that a BDB JE application using JE 5.0 can use environments written with older versions of JE. However, it's not backwards compatible; once your environment has been opened by JE 5.0, it's been converted to the new format, and can no longer be readable by older versions of JE.
Just for the benefit of others who may not have read the changelog, here's the full text:
JE 5.0.34 has moved to on-disk file format 8.
The change is forward compatible in that JE files created with release 4.1 and earlier can be read when opened with JE 5.0.34. The change is not backward compatible in that files created with JE 5.0 cannot be read by earlier releases. Note that if an existing environment is opened read/write, a new log file is written by JE 5.0 and the environment can no longer be read by earlier releases.
There are two important notes about the file format change.
The file format change enabled significant improvements in the operation performance, memory and disk footprint, and concurrency of databases with duplicate keys. Environments which contain databases with duplicate keys must run an upgrade utility before opening an environment with this release. See the Performance section for more information.
An application which uses JE replication may not upgrade directly from JE 4.0 to JE 5.0. Instead, the upgrade must be done from JE 4.0 to JE 4.1 and then to JE 5.0. Applications already at JE 4.1 are not affected. Upgrade guidance can be found in the new chapter, "Upgrading a JE Replication Group", in the "Getting Started with BDB JE High Availability" guide.I may not have fully understood your question, so let us know if that doesn't answer it.
Edited by: Linda Lee on Dec 1, 2011 10:41 AM