JE 5.0.55 and 4.1.21 available, critical fix for Database renaming

Question

All,
I'd like to point out the critical bug fix that has to do with database renaming. This is fixed in JE 5.0.55 and JE 4.1.21. See below.
--mark
Berkeley DB Java Edition 5.0.55
http://www.oracle.com/us/products/database/berkeley-db/index.html (BDB product page)
http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html (BDB overview)
http://www.oracle.com/technetwork/database/berkeleydb/overview/index-093405.html (BDB JE overview)
Berkeley DB Java Edition 5.0.55 is a patch release consisting of fixes for a number of issues. We strongly recommend that users of the 5.0.x version upgrade to this release. These fixes include:
[#21537] Fixed a critical bug that causes a database to be entirely deleted after a crash (or abnormal shutdown, i.e., when not calling Environment.close). The bug occurs when the database is renamed just prior to the crash (or abnormal shutdown). This bug was introduced in JE 5.0.48.
[#21492] Fixed an inefficiency in the Checkpointer which manifests itself as a large amount of time being spent in com.sleepycat.je.recovery.DirtyINMap.removeNextNode() calling java.util.HashMap$HashIterator.remove() calling java.util.HashMap.removeEntryForKey().
[#21106] An enhancement has been made to DbVerify to show a histogram of BIN counts by utilization percentage.This is a sample of the output:
    Verifying database p10
    Checking tree for p10
    BTree: Composition of btree, types and counts of nodes.
            binCount=3,207
            binEntriesHistogram=[40-49%: 3,093; 50-59%: 10; 60-69%: 22; 70-79%: 26;
    80-89%: 21; 90-99%: 35]
            binsByLevel=[level 1: count=3,207]
            deletedLNCount=0
            inCount=49
            insByLevel=[level 2: count=48; level 3: count=1]
            lnCount=209,716
            mainTreeMaxDepth=3Find the complete list of changes in the change log.
http://download.oracle.com/otndocs/products/berkeleydb/html/je/je-5.0.55_changelog.html
Read the detailed product documentation included in the download package or on the web.
http://www.oracle.com/technetwork/database/berkeleydb/downloads/index-098622.html
http://download.oracle.com/docs/cd/E17277_02/html/index.html
Download the source code.
http://download.oracle.com/otn/berkeley-db/je-5.0.55.tar.gz
http://download.oracle.com/otn/berkeley-db/je-5.0.55.zip
http://download.oracle.com/maven/com/sleepycat/je/5.0.55/je-5.0.55.pom
Review the frequently asked questions (FAQs):
http://www.oracle.com/technetwork/database/berkeleydb/je-faq-096044.html
Join OTN and participate in the Berkeley DB JE Support Forum discussions. Our engineering and support staff are highly active on these forums, if you have questions please ask them there first.
Berkeley DB Java Edition
For further information, or questions about licensing and sales of JE, please contact us at:
mailto:[email protected]
Thank you for your support of Berkeley DB Java Edition.

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