Berkeley DB Java Edition
Release Notes

1.5.3, September 03, 2004

These release notes contain:

Overview

Berkeley DB Java Edition (JE) is a 100% pure Java implementation of Berkeley DB. It implements a transactional store model based on a B-Tree access method.

JE's capabilities and features are described in the Getting Started with Berkeley DB Java Edition guide. That document also introduces the JE API set. For a complete description of the JE API set, see the Javadoc. For a description of how to use JE and the Sleepycat Java Collections API, see the collections tutorial.

New in this Release

This is the 1.5.3 release of Berkeley DB Java Edition. This release contains the performance enhancements and bug fixes since release 1.5.1 of the product. Key changes are described below; the complete list of changes can be found in the change log page for this release.

Note: If you are using Mac OS X, please be aware of the following issue. Java version 1.4.2_03 on Mac OS X reports the wrong value for Runtime.maxMemory. JE calculates its default cache size as a percentage of maxMemory. With the default percentage (60%) we calculate a size slightly higher than the actually memory available, so the JVM will run out of memory as JE tries to fill the cache. For Java 1.4.2_03 on Mac OS X only, we have added a workaround [SR #10513] that adjusts the value returned by maxMemory to the correct value. If you are using any other version of Java on Mac OS X, you may have to work around the problem yourself by setting the je.maxMemory property to explicitly specify the size of the JE cache.

Log File On-Disk Format Changes:

New Features:

API Changes:

  1. Change Transaction.getId() to be a public method. It can be useful when correlating transaction statistics to particular transactions. [#10657]

  2. Fix an inconsistency in exception handling. Previously, DeadlockException and LockNotGrantedException were independent exceptions. DeadlockException was thrown in the case of deadlocks and LockNotGrantedException was thrown when a transaction was configured to be non-blocking and a lock was not available.
    Because we generally advise applications to handle only DatabaseException, DeadlockException, or RunRecovery exception, an application could fail if non-blocking transactions are configured because it was not catching LockNotGrantedException. With this change, an application can chose whether to catch the more specific LockNotGrantedException, or simply handle it as generic deadlock. [#10672]

  3. Fix a bug where records larger than 5K were handled inefficiently during operations like environment open and log cleaning because the default read buffer size was too small and was not adaptable. This caused the performance of environment open to be dependent on record size, rather than a function of checkpoint interval. The default read buffer size is now increased to 8K, and will grow if larger records are encountered.
    Two new methods, EnvironmentStats.getNRepeatIteratorReads() and EnvironmentStats.getNRepeatFaultReads() and a new je property, je.log.iteratorMaxSize,have been added to allow more fine tuning of the efficiency of the read buffer. [#10749]

Collections and Bind Changes:

  1. Improve compatibility between our custom serialization (StoredClassCatalog) and applications that use custom class loaders. [#10827]

Performance Changes:

  1. Change checkpoints to delete cleaned files, rather than waiting for the cleaner to finish. This prevents the cleaner from becoming back logged when a crash occurs during a cleaner run. It also minimizes the number of checkpoints since the cleaner does not perform a checkpoint at the end of each cleaner run. Cleaned files are deleted when more than five files have been cleaned at the time a checkpoint starts. The new property je.cleaner.minFilesToDelete can be used to override the default of five files. [#10756]

  2. Improve recovery performance for opening an existing environment for databases that do not support duplicates. [#10781]

Known Bugs

This section is updated regularly.

  1. The results of a Database.truncate() call are seen by other methods executed from that same Database handle, even if they use other transactions.[#10339]

  2. Using the same database and transaction handles to insert data after a truncate causes a deadlock. For example, the following code fragment will deadlock:
      myDatabase.truncate(txnA, ...)
      myDatabase.put(txnA, ...);
      
    A workaround is to commit the transaction after the truncate. [#10386]


  3. Unutilized disk space resulting from a Database.truncate() or Environment.removeDatabase() may not be cleaned if the environment is not closed normally.

Copyright (c) 1996-2004 Sleepycat Software, Inc. - All rights reserved.