The changes between 3.2.74 and 3.2.76 are described directly below. A full list of all changes since JE 2.1.34 is also available below.
All changes from JE 3.0.11, 3.0.12, 3.1.0, 3.2.13, 3.2.21, 3.2.23 and 3.2.76 are listed here.
For additional details, please see the documentation and Release Notes included in your download package or on our website.
The change is forward compatible in that JE files created with release 3.1.0 and earlier can be read when opened with JE 3.2.13. The change is not backward compatible in that files created with JE 3.2.13 cannot be read by earlier releases. Note that if an existing environment is opened read/write, a new log file is written by JE 3.2.13 and the environment can no longer be read by earlier releases.[#15195] (3.2.13)
com.sleepycat.je.DatabaseException: JE 3.0.11: searchResult=class com.sleepycat. je.tree.IN nodeId=479 nEntries=0 at com.sleepycat.je.tree.Tree.getParentBINForChildLN(Tree.java:1031) ... Caused by: java.lang.ClassCastException: com.sleepycat.je.tree.IN at com.sleepycat.je.tree.Tree.getParentBINForChildLN(Tree.java:1021)(3.0.11)
JE 3.0.11 introduced the beta release of the DPL, while JE 3.1 is the GA release. Please see the Release Notes for more information. [#13894]
com.sleepycat.je.util.DbBackupis a new helper class which simplifies backups by managing JE background activity in an open environment. See the Getting Started Guide, Chapter 7 (Backing up and Restoring Berkeley DB Java Edition Applications) and the Javadoc for DbBackup for more information. [#14022](3.0.11)
com.sleepycat.collectionspackage is now fully compatible with the Java Collections framework. In previous releases,
Collections.size()was not supported, and collection iterators had to be explicitly closed. These incompatibilities have been addressed to provide full interoperability with other Java libraries that use the Java Collections Framework interfaces. [#14154] [#12986](3.0.11)
com.sleepycat.bind.tuplepackage now has bindings that correctly sort negative floating point numbers. See the following new APIs:
SortedFloatBinding, SortedDoubleBinding, TupleInput.readSortedFloat, TupleInput.readSortedDouble, TupleOutput.writeSortedFloat, TupleOutput.writeSortedDouble.[#14127](3.0.11)
This functionality is also exposed through the new method com.sleepycat.persist.EntityIndex.count() and is also used by com.sleepycat.collections.StoredMap.size() and com.sleepycat.collections.StoredCollection.size(). See the Javadoc for full details. [#14060](3.1.0)
com.sleepycat.bind.tuple.TupleInput.readBigInteger com.sleepycat.bind.tuple.TupleOutput.writeBigInteger com.sleepycat.bind.tuple.BigIntegerBinding[#15244] (3.2.13)
One workaround for the user was to use -Dje.disable.java.adler32=true at runtime. This forces JE to its own, slower Adler32 implementation. It's an existing flag that was used to work around a Java 1.4 problem with the Adler32 implementation.
A second workaround provided in (3.1.0) is the je.adler32.chunkSize property. Setting this parameter will cause JE to pass chunks of the log record to the checksumming class so that the GC does not block. 0 means do not chunk.
Note that the Adler32 memory allocation issue is reported in this Sun bug entry to be fixed in various releases of the Sun JVM. [#14149] (3.1.0)
java.lang.NullPointerException at com.sleepycat.je.cleaner.UtilizationProfile.getCheapestFileToClean(UtilizationProfile.java:201) at com.sleepycat.je.cleaner.FileSelector.selectFileForCleaning(FileSelector.java:205) at com.sleepycat.je.cleaner.FileProcessor.doClean(FileProcessor.java:201) at com.sleepycat.je.cleaner.FileProcessor.onWakeup(FileProcessor.java:143)[#14431](3.0.11)
com.sleepycat.util.RuntimeExceptionWrapper: Channel closed, may be due to thread interrupt.[#14571](3.1.0)
<Cleaner name="Cleaner-1"/> caught exception: java.lang.NullPointerException java.lang.NullPointerException at java.util.TreeMap.getEntry(TreeMap.java:324) at java.util.TreeMap.remove(TreeMap.java:580) at java.util.TreeSet.remove(TreeSet.java:259) at com.sleepycat.je.cleaner.FileSelector.selectFileForCleaning(FileSelector.java:236) at com.sleepycat.je.cleaner.FileProcessor.doClean(FileProcessor.java:201) at com.sleepycat.je.cleaner.FileProcessor.onWakeup(FileProcessor.java:143) at com.sleepycat.je.utilint.DaemonThread.run(DaemonThread.java:189) at java.lang.Thread.run(Thread.java:619) Continuing[#14877](3.1.0)
"Thread-20" prio=5 tid=0x00538990 nid=0x1824400 waiting on condition [0xf181f000..0xf1820ab0] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:681) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:711) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1041) at java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync.wlock(ReentrantReadWriteLock.java:342) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:637) at com.sleepycat.je.latch.Java5SharedLatchImpl.acquireExclusive(Java5SharedLatchImpl.java:91) at com.sleepycat.je.tree.IN.latch(IN.java:329) ...[#15142] (3.2.13)
Exception in thread "Thread-0" java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448) at java.util.AbstractList$Itr.next(AbstractList.java:419) at com.sleepycat.je.latch.SharedLatchImpl.indexOf(SharedLatchImpl.java:246) at com.sleepycat.je.latch.SharedLatchImpl.acquireExclusiveNoWait(SharedLatchImpl.java:131) at com.sleepycat.je.tree.IN.latchNoWait(IN.java:352) ...[#15231] (3.2.13)
Exception in thread "Thread-0" java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:275) at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1180) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:576) at com.sleepycat.je.latch.Java5SharedLatchImpl.releaseIfOwner(Java5SharedLatchImpl.java:227) at com.sleepycat.je.tree.IN.releaseLatchIfOwner(IN.java:405) at com.sleepycat.je.tree.Tree.searchSplitsAllowed(Tree.java:1701) at com.sleepycat.je.tree.Tree.findBinForInsert(Tree.java:3321) at com.sleepycat.je.tree.Tree.insert(Tree.java:2475) ...[#15233] (3.2.13)
com.sleepycat.je.RunRecoveryException: java.nio.BufferOverflowException at com.sleepycat.je.log.LogManager.log(LogManager.java:284) at com.sleepycat.je.log.LogManager.log(LogManager.java:181) at com.sleepycat.je.log.TraceLogHandler.publish(TraceLogHandler.java:41) at java.util.logging.Logger.log(Logger.java:428) at java.util.logging.Logger.doLog(Logger.java:450) at java.util.logging.Logger.log(Logger.java:473) at com.sleepycat.je.utilint.Tracer.trace(Tracer.java:71) at com.sleepycat.je.recovery.RecoveryManager.undoLNs(RecoveryManager.java:995) at com.sleepycat.je.recovery.RecoveryManager.buildTree(RecoveryManager.java:428) at com.sleepycat.je.recovery.RecoveryManager.recover(RecoveryManager.java:153) at com.sleepycat.je.dbi.EnvironmentImpl.<init>(EnvironmentImpl.java:338) at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:101) at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:53) at com.sleepycat.je.Environment.<init>(Environment.java:100) at com.sleepycat.je.XAEnvironment.<init>(XAEnvironment.java:35)This problem was reported in this JE forum thread, and a patch was posted there. [#15293] (3.2.21)
com.sleepycat.je.DatabaseException: (JE 3.0.12) Database XXX id=404 IN type=BIN/2 id=3335404 not expected on INList at com.sleepycat.je.evictor.Evictor.selectIN(Evictor.java:469) at com.sleepycat.je.evictor.Evictor.evictBatch(Evictor.java:330) at com.sleepycat.je.evictor.Evictor.doEvict(Evictor.java:242) at com.sleepycat.je.evictor.Evictor.doCriticalEviction(Evictor.java:266) at com.sleepycat.je.dbi.CursorImpl.close(CursorImpl.java:666) at com.sleepycat.je.Cursor.close(Cursor.java:243) at com.sleepycat.je.Database.putInternal(Database.java:571) at com.sleepycat.je.Database.putNoOverwrite(Database.java:530)This problem was reported in this JE forum thread. [#15317] (3.2.21)
java.lang.AssertionError at com.sleepycat.je.latch.Java5SharedLatchImpl.releaseIfOwner(Java5SharedLatchImpl.java:205).This problem was reported in this JE forum thread. [#15329] (3.2.21)
at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x06bc5308> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(Unknown Source) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Unknown Source) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(Unknown Source) at java.util.concurrent.locks.ReentrantLock.lock(Unknown Source) at com.sleepycat.je.latch.Java5LatchImpl.acquire(Java5LatchImpl.java:84) at com.sleepycat.je.dbi.INList.latchMinor(INList.java:309) at com.sleepycat.je.dbi.INList.latchMinorAndDumpAddedINs(INList.java:298) at com.sleepycat.je.dbi.INList.releaseMajorLatch(INList.java:284) at com.sleepycat.je.dbi.MemoryBudget.calcTreeCacheUsage(MemoryBudget.java:586) at com.sleepycat.je.dbi.MemoryBudget.initCacheMemoryUsage(MemoryBudget.java:563) at com.sleepycat.je.dbi.EnvironmentImpl.<init>(EnvironmentImpl.java:368) at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:101)[#15364] (3.2.21)
at java.io.File.exists(File.java:733) at com.sleepycat.je.cleaner.UtilizationProfile.putFileSummary(UtilizationProfile.java:747) at com.sleepycat.je.cleaner.UtilizationTracker.evictMemory(UtilizationTracker.java:118) at com.sleepycat.je.evictor.Evictor.evictBatch(Evictor.java:313) at com.sleepycat.je.evictor.Evictor.doEvict(Evictor.java:253)[#15512]
This limitation will be removed in a future release in order to allow changing the data of a record in a database with duplicates configured, when a custom duplicate comparator is used that does not compare all data bytes. But note that even then, changing the sort order of a duplicate will not be possible by updating the record. To change the sort order of any record (with or without duplicates configured), you must delete and then re-insert the record.
The problem was reported in this JE Forum thread. [#15527] (3.2.28)
com.sleepycat.je.latch.LatchException: (JE 3.2.23) BIN45 already held at com.sleepycat.je.latch.Java5SharedLatchImpl.acquireExclusive(Java5SharedLatchImpl.java:87) at com.sleepycat.je.tree.IN.latch(IN.java:326) at com.sleepycat.je.tree.IN.latch(IN.java:365) at com.sleepycat.je.dbi.CursorImpl.latchBIN(CursorImpl.java:457) at com.sleepycat.je.tree.Tree.insertDuplicate(Tree.java:2879)The problem was reported in this JE Forum thread [#15574](3.2.31)
com.sleepycat.je.DatabaseException: (JE 3.2.29) fetchTarget of null lsn parent IN=226141 lastFullVersion=0xffffffff/0xffffffff parent.getDirty()=true state=10 NULL_LSN without KnownDeleted com.sleepycat.je.DatabaseException: (JE 3.2.29) fetchTarget of null lsn parent IN=226141 lastFullVersion=0xffffffff/0xffffffff parent.getDirty()=true state=10 NULL_LSN without KnownDeleted at com.sleepycat.je.tree.IN.fetchTarget(IN.java:942) at com.sleepycat.je.tree.BIN.compress(BIN.java:670) at com.sleepycat.je.incomp.INCompressor.compressBin(INCompressor.java:503) at com.sleepycat.je.incomp.INCompressor.doCompress(INCompressor.java:414) at com.sleepycat.je.incomp.INCompressor.onWakeup(INCompressor.java:342) at com.sleepycat.je.utilint.DaemonThread.run(DaemonThread.java:191)The problem was reported in this JE Forum thread [#15588](3.2.32)
If the timing is right, the previously existing record would not be restored correctly when the transaction is aborted. Instead of having key K it would have key K'. When the previously existing record is returned by a query, key K' would be incorrectly returned.
The same thing could occur for data elements (rather than keys) when using a duplicates database with a custom duplicate comparator (rather than a custom btree comparator).
This problem was initially reported in this JE Forum thread. [#15704](3.2.49)
com.sleepycat.je.DatabaseException: (JE 3.2.44) Database relations_database14269 id=26 rootLsn=0xffffffff/ 0xffffffff IN type=DBIN/2 id=29976291 not expected on INList at com.sleepycat.je.evictor.Evictor.selectIN(Evictor.java:511) at com.sleepycat.je.evictor.Evictor.evictBatch(Evictor.java:354) at com.sleepycat.je.evictor.Evictor.doEvict(Evictor.java:249) at com.sleepycat.je.evictor.Evictor.doCriticalEviction(Evictor.java:274) com.sleepycat.je.DatabaseException: (JE 3.2.21) can't find database 8188589 at com.sleepycat.je.dbi.DbTree.modifyDbRoot(DbTree.java:270) at com.sleepycat.je.recovery.Checkpointer.flushIN(Checkpointer.java:746) at com.sleepycat.je.recovery.Checkpointer.flushDirtyNodes(Checkpointer.java:669) at com.sleepycat.je.recovery.Checkpointer.doCheckpoint(Checkpointer.java:447)This bug was reported in two forum threads:
Caused by: com.sleepycat.je.DatabaseException: (JE 3.2.68) last LSN=0x0/0x1d2 at com.sleepycat.je.recovery.RecoveryManager.traceAndThrowException(RecoveryManager.java:2365) at com.sleepycat.je.recovery.RecoveryManager.redoLNs(RecoveryManager.java:1182) at com.sleepycat.je.recovery.RecoveryManager.buildTree(RecoveryManager.java:440) at com.sleepycat.je.recovery.RecoveryManager.recover(RecoveryManager.java:153) at com.sleepycat.je.dbi.EnvironmentImpl.<init>(EnvironmentImpl.java:348) at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:102) at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:54) at com.sleepycat.je.Environment.<init>(Environment.java:103) Caused by: java.lang.NullPointerException at com.sleepycat.je.utilint.DbLsn.compareTo(DbLsn.java:76) at com.sleepycat.je.recovery.RecoveryManager.redoLNs(RecoveryManager.java:1081) ... 34 moreThe log has no user data and only holds the beginning of JE internal data structures so no data is lost, but the environment can't be reopened until the log file is removed. The problem was initially reported in this JE Forum thread. (3.2.74)[#16016]
com.sleepycat.je.jca.ra.JEConnection.removeDatabase(), com.sleepycat.je.jca.ra.JEConnection.truncateDatabase()to support database truncation and removal for JCS users. [#15105]
Environment.scanLog()which allows programmatic scanning of the JE log. The function and restrictions are detailed in the javadoc. [#15532](3.2.49)
java.lang.UnsupportedClassVersionError: Bad version number in .class fileor
class file has wrong version 50.0, should be 49.0The DPL classes have been rebuilt to target Java 1.5. This problem was introduced in JE 3.2.42. The problem was reported in this JE Forum thread Note that in Java 1.6, if "-source 1.5" is specified this does not cause "-target 1.5" to be the default target setting. This is a change to javac in Java 1.6 and was the source of the JE build problem. [#15675] (3.2.43)
.../test/regress does not exist!The JE build now creates this directory if it is missing. This problem was introduced in JE 3.2.42. The problem was reported in this JE Forum thread. [#15679] (3.2.43)
je.log.useODSYNC, has been added which causes all JE log files (
*.jdb) to be opened using the
O_DSYNCflag. This causes all JE writes to be written directly to disk before the
write()call returns (rather than forced later when
fsync()is called). The default value for this parameter is
false(do not force each
This property should always be set to
true when the environment directory resides on a "remote" system accessed using (e.g.) NFS or SMB and should be set to
false when the environment directory is on a local disk.
JE expects the
write system call to flush data to the operating system, and the
fsync system call to flush data to disk. Depending on the remote file system configuration, some systems may cache data from
write() calls on the server side, even after control is returned to the calling client (JE), which makes JE unable to guarantee the consistency of the log. Setting this property to
true prevents server-side caching and guarantees that all remote
write() calls are durable. Enabling this parameter will cause some performance degradation, varying by system and workload. [#15775] (3.2.62)
"UnsupportedOperationException: Class evolution is not supported"was thrown when performing class enhancement. This problem would occur when creating a store without enhancing classes and then using enhancement later, or when creating a store with class enhancement and then not using enhancement later. [#14651](3.0.12)
"ArrayIndexOutOfBoundsException: 2147483646"was thrown when updating a record with a secondary key. The problem occurred when a single instance was used for both the primary key and secondary key fields. [#14665](3.0.12)
"IllegalArgumentException: Class is not persistent"was thrown for a class that was correctly made persistent using a proxy class. The problem occurred when one proxy class referenced another. [#14665](3.0.12)
java.lang.StringIndexOutOfBoundsException: String index out of range: -9 at java.lang.String.substring(Unknown Source) at com.sleepycat.persist.impl.Store.getStoreNames(Store.java:209) at com.sleepycat.persist.EntityStore.getStoreNames(EntityStore.java:186)[#14978]
java.lang.StringIndexOutOfBoundsException: String index out of range: -9 at java.lang.String.substring(Unknown Source) at com.sleepycat.persist.impl.Store.getStoreNames(Store.java:209) at com.sleepycat.persist.EntityStore.getStoreNames(EntityStore.java:186)[#14978](3.1.0)
Fixed a bug where all secondary databases were not opened in a single transactional along with the primary database as documented. This bug has not been reported from the field and is unlikely to have caused a problem, since database open rarely fails except as the result of a catastrophic error, in which case the store would not be usable anyway. But when the new method setSecondaryBulkLoad(true) is used, a secondary database could fail to open while populating it if a foreign key constraint is violated. [#15525] (3.2.31)
java.lang.IllegalArgumentException: Key field object may not be null at com.sleepycat.persist.impl.RecordOutput.writeKeyObject(RecordOutput.java:101) at com.sleepycat.persist.impl.RawAccessor.writeField(RawAccessor.java:219) at com.sleepycat.persist.impl.RawAccessor.writeSecKeyFields(RawAccessor.java:114) at com.sleepycat.persist.impl.ComplexFormat.writeObject(ComplexFormat.java:479) at com.sleepycat.persist.impl.PersistEntityBinding.writeEntity(PersistEntityBinding.java:114) at com.sleepycat.persist.impl.PersistKeyCreator.nullifyForeignKey(PersistKeyCreator.java:139) ...The problem was initially reported in this JE Forum Thread.[#15733](3.2.49)
This bug was reported on this forum thread. An example stack trace follows, although the stack trace for this problem varies.
java.lang.IndexOutOfBoundsException at com.sleepycat.bind.tuple.TupleInput.readUnsignedInt(TupleInput.java:414) at com.sleepycat.bind.tuple.TupleInput.readInt(TupleInput.java:233) at com.sleepycat.persist.impl.SimpleFormat$FInt.readPrimitiveField(SimpleFormat.java:403) at com.sleepycat.persist.impl.ReflectionAccessor$PrimitiveAccess.read(ReflectionAccessor.java:429) at com.sleepycat.persist.impl.ReflectionAccessor.readNonKeyFields(ReflectionAccessor.java:274) at com.sleepycat.persist.impl.ComplexFormat$PlainFieldReader.readFields(ComplexFormat.java:1606) at com.sleepycat.persist.impl.ComplexFormat$MultiFieldReader.readFields(ComplexFormat.java:1814) at com.sleepycat.persist.impl.ComplexFormat$EvolveReader.readObject(ComplexFormat.java:1943) at com.sleepycat.persist.impl.PersistEntityBinding.readEntity(PersistEntityBinding.java:88) at com.sleepycat.persist.impl.PersistEntityBinding.entryToObject(PersistEntityBinding.java:58) at com.sleepycat.persist.EntityValueAdapter.entryToValue(EntityValueAdapter.java:56) at com.sleepycat.persist.BasicCursor.returnValue(BasicCursor.java:206) at com.sleepycat.persist.BasicCursor.next(BasicCursor.java:74) at com.sleepycat.persist.BasicIterator.hasNext(BasicIterator.java:50)[#15524] (3.2.55)
If you are upgrading from a release of JE that is 2.0.90 or earlier, then you should ensure that you call Environment.close() prior to upgrading. If you do not close the environment cleanly, and you have very recently created a new database, you may see the following exception:
com.sleepycat.je.DatabaseException: JE 3.0.11: searchResult=class com.sleepycat. je.tree.IN nodeId=479 nEntries=0 at com.sleepycat.je.tree.Tree.getParentBINForChildLN(Tree.java:1031) ... Caused by: java.lang.ClassCastException: com.sleepycat.je.tree.IN at com.sleepycat.je.tree.Tree.getParentBINForChildLN(Tree.java:1021)
The data in the environment was not corrupted, and the environment can be successfully opened with the following steps which remove any new files create by JE 3.0.11, and then call Environment.close() prior to upgrading.
To remove any data created by JE 3.0.11:
-rwx------ 1 cwl other 19629 May 5 11:26 00000000.jdb -rw-r--r-- 1 cwl other 3014 May 8 11:36 00000001.jdb <-- new file
java com.sleepycat.je.util.DbPrintLog -h <envhome> -s <lastfilenumber>where <lastfilenumber> is a hex number of the last file (e.g. '-s 0x1' in the case above). You should see output like this:
<DbPrintLog> <entry lsn="0x1/0x0" type="FileHeader/0" prev="0x0" size="24" cksum="800588407"><FileHeader num="0x1" lastEntryInPrevFileOffset="0x4c87" logVersion="0x4" time=" 2006-05-08 12:50:20.63"/></entry> ...The first file header record shows a logVersion of 0x4. These files were written during the attempted upgrade and can be deleted.
To close the environment cleanly after any JE 3.0.11 data has been removed:
java -cp "je-1.7.1.jar:je-3.0.11.jar" com.sleepycat.je.util.DbRunAction -h <envdir>Since DbRunAction is not present in releases prior to 2.1.30, you should include the latest release in the classpath, but after the old release. That will run a checkpoint on the old environment using the old version of JE. Several lines of output will be produced. Verify that the last log file was written to by taking a directory listing.
java -cp "je-3.0.11.jar" com.sleepycat.je.util.DbRunAction -h <envdir>