Berkeley DB Java Edition 3.2.13 Change Log
The changes between 3.1.0 and 3.2.13 are described directly below. A
full list of all changes since JE 2.1.34 is also available below.
Changes since 3.1.0
Log File On-Disk Format Changes:
-
JE 3.2.13 has moved to on-disk file format 5.
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]
New Features:
-
Added three new configuration properties to limit the amount of I/O performed
by JE background activities such as cleaning and checkpointing:
je.env.backgroundReadLimit, je.env.backgroundWriteLimit,
je.env.backgroundSleepInterval. The amount of I/O performed by JE background
threads sometimes spikes, which increases the response time (latency) of user
operations that are performed in other threads. By setting these new
properties, an application can limit the amount of background I/O in order to
reduce the the response time of user operations.
[#15158][Metalink 5839909.993]
-
Tuple bindings now support the java.math.BigInteger type. Like other tuple
binding values, BigInteger values are sorted in natural integer order by
default, without using a custom comparator. For details please see the Javadoc
for:
com.sleepycat.bind.tuple.TupleInput.readBigInteger
com.sleepycat.bind.tuple.TupleOutput.writeBigInteger
com.sleepycat.bind.tuple.BigIntegerBinding
[#15244]
-
The java.math.BigInteger class is now a DPL simple type. Values of this type
are sorted in natural integer order by default, and BigInteger can be used as
the type of a primary or secondary key field. DPL class evolution will
automatically widen all other integer types (byte, char, short, int, long) to a
BigInteger -- in an existing class, changing from any of these types to
BigInteger is a compatible type change. [#15244]
-
The JE Deferred Write mode is now explicitly available in the
DPL. Deferred Write mode may be set for an entire DPL store using
StoreConfig.setDeferredWrite and all index changes may be flushed to
disk using EntityStore.sync. [#15249]
-
When setting the Environment configuration property je.log.memOnly to true, a
non-existent environment directory may now be specified and the je.lock file
will not be written. Note that memory-only mode is primarily useful with
automated tests to avoid file cleanup and it not recommended for production
use. If you need a low durability mode for production use, see the Deferred
Write mode (Database.setDeferredWrite). [#15255]
General Environment Changes
-
Fixed a bug where JE incorrectly handled the case where the
environment consists of a single log file, there is a checksum
error immediately following the file header, and the application
repeatedly attempts to open the environment without heeding the
DatabaseExceptions thrown by new Environment(). The first two open attempts
correctly warned the application that the 00000000.jdb file should
be moved away; the third attempt incorrectly threw a ClassCastException.
[#15133][Metalink 5802188.992]
-
Fixed a bug where latches were not released when a
LockNotGrantedException was thrown, resulting in a deadlock. This
problem only applies to applications which use
TransactionConfig.setNoWait(). One symptom of the problem are threads
which are waiting on com.sleepycat.je.tree.IN.latch, in this manner:
"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]
-
A minor change was made to the way that checkpoints are scheduled. As a
result, checkpoints are performed at slightly more regular intervals than
before. [#15169]
-
Fix a bug where a monitor (synchronized lock) deadlock could occur under low
memory conditions. This problem was discovered during internal testing and has
not been reported from the field. [#15176]
-
Improve log cleaning by improving the counting of obsolete record sizes. The
utilization of a given log file is now known more accurately, which means that
cleaning can be more efficient. The improvement impacts applications that
insert both large and small records, and that delete or update them
asymmetrically; for example, both large and small records are inserted but only
small records are deleted. A new Environment configuration property was also
added: je.cleaner.fetchObsoleteSize; if set to true, this property causes log
records to be fetched in order to count their sizes accurately when a database
is truncated or removed, and when running recovery.
[#15195] Metalink: 5872288.993
-
Fixed a bug where the wrong comparator could be used in the first insertion of
a duplicate record when the application has specified both a custom
BtreeComparator and a custom DuplicateComparator. [#15197]
-
Fixed a race condition which could occur when there are concurrent Environment
instantiations and closings. An application could erroneously get access to a
invalidated (closed) Environment instance. [#15200]
-
Fixed a bug in JE's management of its internal utilization statistics
which could result in an OutOfMemoryError. The problem was initially reported
on this JE
Forum thread.
This bug sometimes caused OutOfMemoryError when both of the following
conditions occurred: 1) A very large data set is used or the applications runs
for a very long internal without closing the environment, and 2) the cache is
large enough to fit all data records into memory. [#15214]
-
Fixed a bug which could result in a ConcurrentModificationException
and this stack trace when running under Java 1.4.
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]
-
Fixed a bug which could occur when je.env.sharedLatches=true and the
application is executing inserts, which manifested as this
intermittent stack trace:
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]
-
Database.sync now flushes the log to disk so that all changes are durable.
Before, some changes might not be durable if a crash occurred after the sync
and prior to the log buffer naturally being written as further changes were
made or during the next checkpoint or Environment.close. [#15254]
Direct Persistence Layer (DPL)
-
Fixed a bug where the wrong key class was validated when calling
EntityStore.getSecondaryIndex for a read-only store with a TO_MANY secondary.
The application would see an IllegalArgumentException prefixed with "Wrong
secondary key class:". [#15156]
-
Fixed a bug where the DPL was not working correctly with implicit transactions
in an XA environment. The problem was reported in this JE
Forum thread.. Now, when an XAEnvironment is used, XA transactions are
implicit when a null transaction parameter, or no transaction parameter, is
used in the DPL API. [#15206]
-
Fixed a potential performance problem with secondary indexes that are defined
in entity subclasses. When an instance of an entity subclass is stored (via
PrimaryIndex.put), we now create any secondary indexes that are defined on that
subclass. Before, the secondary indexes were not created until
EntityStore.getSubclassIndex was called. This was not technically a bug, since
there was no loss of data and secondary indexes were created when they were
used. But now the index is created as soon as possible, so that the index does
not have to populated from scratch when it is first accessed. [#15247]
API Changes:
-
For debugging usage, DatabaseEntry.toString() now outputs the data as decimal
bytes. The new DatabaseEntry.MAX_DUMP_BYTES (default 100) static field can be
changed to limit the number of bytes that are output. [#15248]
Utility Changes:
-
com.sleepycat.je.util.DbCacheSize is now callable programmatically, in addition
to being usable as a command line program. A new option, -r, for recalculating
utilization is also available. DbCacheSize is not an officially supported
utility and is not documented; for details, please see the DbCacheSize.java
source file. [#15217]
Configuration, Documentation, Test and Build Changes:
-
Fixed Javadoc for EnvironmentMutableConfig.setTxnWriteNoSync(). The Javadoc
for this method incorrectly stated that this type of durability would not
survive JVM failures. setTxnWriteNoSync style durability does, in fact,
survive JVM crashes.
-
The Javadoc for the com.sleepycat.persist.SecondaryIndex class was enhanced to
discuss: One-to-Many versus Many-to-One for Related Entities; Key Placement
with Many-to-Many for Related Entities; and Many-to-Many Versus a Relationship
Entity.
-
The Java Collections Tutorial and associated example code was updated to remove
mention of StoredIterator and the requirement to close stored iterators. As of
JE 3.0.11, iterators over stored collections no longer need to be closed.
[#15202]
-
Several sporadic test failures were fixed and the test suite ("ant test")
should now run reliably on all platforms.
All changes from JE 3.0.11, 3.0.12, 3.1.0 and 3.2.13 are listed
here.
For additional details, please see the documentation and Release
Notes included in your download package or on our website.
Log File On-Disk Format Changes:
-
JE 3.2.13 has moved to on-disk file format 5.
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)
- JE 3.0.11 has moved to on-disk file format 4.
The change is forward compatible in that JE files created with
release 2.1.30 and earlier can be read when opened with JE 3.0.11.
The change is not backward compatible in that files created
with JE 3.0.11 cannot be read by earlier releases. Note that if an
earlier environment is opened read/write, a new log file is written by
JE 3.0.11 and the environment can no longer be read by earlier
releases. (3.0.11)
-
An upgrade problem was inadvertently introduced between JE 2.0.90,
which was released in Nov 1, 2005 and the following JE 2.1.34 release
in January 2006. The problem does not apply to you if you have an
environment created with JE 2.0.90 or earlier, and have since
successfully opened it with JE 2.1.30. Likewise, a 2.0.90 and earlier
environment that has been closed cleanly with Environment.close() will
not encounter this problem, nor will most environments that have more
than 30 Mb of data. The problem manifests as the following stack
trace. A workaround is described below.
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)
New Features:
-
A new Direct Persistence Layer adds a built-in Plain Old Java Object
(POJO)-based persistent object model, which provides support for
complex object models without compromises in performance. For an
introduction to the Direct Persistence Layer API, see Getting
Started with the Direct Persistence Layer.
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]
-
A new "deferred write" database mode provides better performance for
temporary databases or databases which rapidly modify data by reducing
the amount of I/O incurred. In a normal durable database, every new
version of a data record is written to disk; in deferred write mode,
JE avoids disk I/O until cache is exceeded or Database.sync() is
called. See the Getting Started Guide, Chapter 3 (Databases) for more
information. [#13936](3.0.11)
-
com.sleepycat.je.util.DbBackup
is 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)
-
The
com.sleepycat.collections
package 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)
-
The
com.sleepycat.bind.tuple
package 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)
-
Added a new method, com.sleepycat.je.Database.count(), which has been
optimized to execute faster than the count obtained from a database
scan. Note that the count may not be accurate in the face of
concurrent update operations.(3.1.0)
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)
-
A new method, EnvironmentConfig.setExceptionListener() provides a
notification mechanism for asynchronous exceptions thrown by JE daemon
threads. See the Javadoc for more details. [#15018](3.1.0)
-
Added three new configuration properties to limit the amount of I/O performed
by JE background activities such as cleaning and checkpointing:
je.env.backgroundReadLimit, je.env.backgroundWriteLimit,
je.env.backgroundSleepInterval. The amount of I/O performed by JE background
threads sometimes spikes, which increases the response time (latency) of user
operations that are performed in other threads. By setting these new
properties, an application can limit the amount of background I/O in order to
reduce the the response time of user operations.
[#15158][Metalink 5839909.993] (3.2.13)
-
Tuple bindings now support the java.math.BigInteger type. Like other tuple
binding values, BigInteger values are sorted in natural integer order by
default, without using a custom comparator. For details please see the Javadoc
for:
com.sleepycat.bind.tuple.TupleInput.readBigInteger
com.sleepycat.bind.tuple.TupleOutput.writeBigInteger
com.sleepycat.bind.tuple.BigIntegerBinding
[#15244] (3.2.13)
-
The java.math.BigInteger class is now a DPL simple type. Values of this type
are sorted in natural integer order by default, and BigInteger can be used as
the type of a primary or secondary key field. DPL class evolution will
automatically widen all other integer types (byte, char, short, int, long) to a
BigInteger -- in an existing class, changing from any of these types to
BigInteger is a compatible type change. [#15244] (3.2.13)
-
The JE Deferred Write mode is now explicitly available in the
DPL. Deferred Write mode may be set for an entire DPL store using
StoreConfig.setDeferredWrite and all index changes may be flushed to
disk using EntityStore.sync. [#15249] (3.2.13)
-
When setting the Environment configuration property je.log.memOnly to true, a
non-existent environment directory may now be specified and the je.lock file
will not be written. Note that memory-only mode is primarily useful with
automated tests to avoid file cleanup and it not recommended for production
use. If you need a low durability mode for production use, see the Deferred
Write mode (Database.setDeferredWrite). [#15255] (3.2.13)
General Environment Changes:
-
Shared latches are now used on all internal nodes of the b-tree, which
increases concurrency for many operations. Shared latches are only
enabled when je.env.sharedLatches is set to true; the default value is
false. The default may change in a future release. [#14168](3.0.11)
-
Fixed a bug where an internal latch was not taken during the deletion
of log cleaning metadata or database metadata. [#14214](3.0.11)
-
Fixed a bug where internal node latches were not released in a corner
case where the database has duplicate records and there are concurrent
readers and writers. [#14230](3.0.11)
-
Calling com.sleepycat.je.Transaction.toString() after the transaction
was closed resulted in a NullPointerException. This is now
fixed. [#14349](3.0.11)
-
In a corner case requiring a certain pattern of inserts coupled with
btree splits and checkpoints, a data record could be lost after an
environment recovery following a non-clean shutdown. This has been
fixed. [#14424](3.0.11)
-
The following NullPointerException could be seen when
je.cleaner.threads > 0. This has been fixed.
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)
-
Cursor.getSearchBothRange() was incorrectly using the custom duplicate
key comparator instead of the main btree key comparator, if the
database was configured with a custom duplicate
comparator. [#14464](3.0.11)
-
A user reported an OutOfMemoryError in a deployment using fairly large
(512K) records. We finally tracked the problem down to the behavior of
the standard java.util.zip.Adler32 class, which JE uses to checksum
log records. Our research found JVM implementation notes which said
that a JVM may temporarily disable garbage collection when executing
the native code for Adler32.
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)
-
Invalidate the Environment when an Error such as
java.lang.OutOfMemoryError is thrown during database operations, so
that RunRecoveryException will be thrown if further operations are
attempted. [#14300](3.1.0)
-
Fixed a bug where high concurrency updates on Java 1.6 could result in
this exception from JE daemon threads:
com.sleepycat.util.RuntimeExceptionWrapper: Channel closed, may
be due to thread interrupt.
[#14571](3.1.0)
-
Fixed a bug that caused a NullPointerException when Database.sync() is
called on a newly created, empty deferred-write database. [#14781](3.1.0)
-
Fixed a bug that caused a NullPointerException in the cleaner thread
when running under a JDK1.6 beta. The exception was not fatal, and
looked like this:
<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)
-
Fixed a bug that resulted in poor cache eviction management, and
therefore poor performance when there is a high level of log cleaning
in conjunction with a high level of cache eviction. This was a
performance regression from the JE 2.1.30 release. One symptom of the
problem is that the ratio of EnvironmentStats.getNBINSsStripped() to
EnvironmentStats.getNNodesSelected() is lower in 3.0 than in 2.1.30.
[#15062](3.1.0)
-
Fixed a bug that resulted in poor cache eviction management and could
trigger OutOfMemoryException. A symptom of the problem is that
EnvironmentStats.getCacheDataBytes() could become negative. [#15129]
-
Fixed a bug where JE incorrectly handled the case where the
environment consists of a single log file, there is a checksum
error immediately following the file header, and the application
repeatedly attempts to open the environment without heeding the
DatabaseExceptions thrown by new Environment(). The first two open attempts
correctly warned the application that the 00000000.jdb file should
be moved away; the third attempt incorrectly threw a ClassCastException.
[#15133][Metalink 5802188.992] (3.2.13)
-
Fixed a bug where latches were not released when a
LockNotGrantedException was thrown, resulting in a deadlock. This
problem only applies to applications which use
TransactionConfig.setNoWait(). One symptom of the problem are threads
which are waiting on com.sleepycat.je.tree.IN.latch, in this manner:
"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)
-
A minor change was made to the way that checkpoints are scheduled. As a
result, checkpoints are performed at slightly more regular intervals than
before. [#15169] (3.2.13)
-
Fix a bug where a monitor (synchronized lock) deadlock could occur under low
memory conditions. This problem was discovered during internal testing and has
not been reported from the field. [#15176] (3.2.13)
-
Improve log cleaning by improving the counting of obsolete record sizes. The
utilization of a given log file is now known more accurately, which means that
cleaning can be more efficient. The improvement impacts applications that
insert both large and small records, and that delete or update them
asymmetrically; for example, both large and small records are inserted but only
small records are deleted. A new Environment configuration property was also
added: je.cleaner.fetchObsoleteSize; if set to true, this property causes log
records to be fetched in order to count their sizes accurately when a database
is truncated or removed, and when running recovery.
[#15195] Metalink: 5872288.993 (3.2.13)
-
Fixed a bug where the wrong comparator could be used in the first insertion of
a duplicate record when the application has specified both a custom
BtreeComparator and a custom DuplicateComparator. [#15197] (3.2.13)
-
Fixed a race condition which could occur when there are concurrent Environment
instantiations and closings. An application could erroneously get access to a
invalidated (closed) Environment instance. [#15200] (3.2.13)
-
Fixed a bug in JE's management of its internal utilization statistics
which could result in an OutOfMemoryError. The problem was initially reported
on this JE
Forum thread.
This bug sometimes caused OutOfMemoryError when both of the following
conditions occurred: 1) A very large data set is used or the applications runs
for a very long internal without closing the environment, and 2) the cache is
large enough to fit all data records into memory. [#15214] (3.2.13)
-
Fixed a bug which could result in a ConcurrentModificationException
and this stack trace when running under Java 1.4.
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)
-
Fixed a bug which could occur when je.env.sharedLatches=true and the
application is executing inserts, which manifested as this
intermittent stack trace:
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)
-
Database.sync now flushes the log to disk so that all changes are durable.
Before, some changes might not be durable if a crash occurred after the sync
and prior to the log buffer naturally being written as further changes were
made or during the next checkpoint or Environment.close. [#15254] (3.2.13)
API Changes:
-
Iterators returned by StoredCollection.iterator() no longer need
closing. The original StoredIterator is now available using the new
StoredCollection.storedIterator() method. See the Release Notes for
more information on collection API changes. [#12986](3.0.11)
-
Database.entry now supports equals() and hashCode(). [#13778](3.0.11)
-
Key comparators can now be stored as serialized objects using the new
DatabaseConfig.setBtreeComparator(Comparator) and
DatabaseConfig.setDuplicateComparator(Comparator) methods. This
allows a single comparator class to handle more than one key format.
[#14422](3.0.11)
-
SecondaryDatabase.delete has been corrected to delete all keys (and
their associated primary records) in the presence of duplicates.
Before, only the first of a duplicate set (and its associated primary)
was deleted. Please note this behavior change. [#14506](3.0.11)
- Added
com.sleepycat.je.jca.ra.JEConnection.removeDatabase(),
com.sleepycat.je.jca.ra.JEConnection.truncateDatabase()
to
support database truncation and removal for JCS users. [#15105]
-
For debugging usage, DatabaseEntry.toString() now outputs the data as decimal
bytes. The new DatabaseEntry.MAX_DUMP_BYTES (default 100) static field can be
changed to limit the number of bytes that are output. [#15248] (3.2.13)
Utility Changes:
-
DbVerify will now verify all databases in the environment if the "-s"
flag is omitted. In previous versions, "-s" was a mandatory
parameter. A new option, "-c" has been added which will check log
cleaner metadata. [#14239](3.0.11)
-
com.sleepycat.je.util.DbCacheSize is now callable programmatically, in addition
to being usable as a command line program. A new option, -r, for recalculating
utilization is also available. DbCacheSize is not an officially supported
utility and is not documented; for details, please see the DbCacheSize.java
source file. [#15217] (3.2.13)
Configuration, Documentation, and Build Changes:
-
Ant 1.6.0 or later is required to build JE from the provided
sources.(3.0.11)
-
The directions in the installation page on how to compile a non-debug
jar were updated.(3.0.11)
-
The "Writing Transactional Applications" guide has been corrected to
make it clear that nested transactions are not yet supported in
JE. [#14079](3.0.11)
-
A variety of problems noted by our faithful readers have been fixed.
-
The examples now specify a character encoding when constructing a
String object.
-
The examples use the base interface type when possible, rather than a
specific collection class.
-
ExampleDatabaseLoad.loadFile() now closes its FileInputStream.
-
Two examples in the Concurrency chapter of the "Writing
Transactional Applications" manual were updated to correctly return
after a commit.
(3.0.11)
- In response to popular demand, the JE jarfile in a JE package is
now named je-<version>.jar instead of just je.jar. For example,
the jar in this release is named je-3.1.0.jar. [#14669](3.1.0)
-
Fixed Javadoc for EnvironmentMutableConfig.setTxnWriteNoSync(). The Javadoc
for this method incorrectly stated that this type of durability would not
survive JVM failures. setTxnWriteNoSync style durability does, in fact,
survive JVM crashes.
-
The Javadoc for the com.sleepycat.persist.SecondaryIndex class was enhanced to
discuss: One-to-Many versus Many-to-One for Related Entities; Key Placement
with Many-to-Many for Related Entities; and Many-to-Many Versus a Relationship
Entity.
-
The Java Collections Tutorial and associated example code was updated to remove
mention of StoredIterator and the requirement to close stored iterators. As of
JE 3.0.11, iterators over stored collections no longer need to be closed.
[#15202] (3.2.13)
-
Several sporadic test failures were fixed and the test suite ("ant test")
should now run reliably on all platforms.
Direct Persistence Layer:
-
Fixed a bug where
"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)
-
Fixed a bug where
"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)
-
Fixed a bug where
"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)
-
Before, if a custom key class (composite key class) was
defined but the @KeyField annotation was not included, an
UnsupportedOperationException would occur when trying to put() a record,
and the exception message was not meaningful. Now, an
IllegalArgumentException will occur when getting the index, with a
meaningful exception message.
[#14673](3.0.12)
-
Class evolution is now implemented in the Direct Persistence Layer.
For more information please see the release notes and the package
specification for the com.sleepycat.persist.evolve package. Also note
that if you have deployed a store using the JE 3.0.12 beta release,
before changing your persistent classes for the first time you must
open and close your store using the JE 3.1 release; see the release
notes for more information. [#14762]
-
Fixed a bug that prevented opening a read-only store when a primary
key sequence was used. [#14941]
- Fixed a bug that prevented using EntityJoin with read-uncommitted
(for example, CursorConfig.READ_UNCOMMITTED). The fix is a change to
JE secondary databases that allows a partial DatabaseEntry to be
passed as the data parameter to a search method, when using
read-uncommitted. [#14966]
-
Fixed a bug in EntityStore.getStoreNames() which resulted in this stack trace:
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]
-
Fixed a bug that caused an IllegalArgumentException when calling
EntityStore.getSecondaryIndex for a @SecondaryKey that was declared on
a superclass of the entity class. [#14978]
-
The EntityStore.getSubclassIndex method has been added. This method
should be used instead of getSecondaryIndex when the secondary key
field is in a subclass of an entity class. The index returned by
getSubclassIndex is used to access only entities of that subclass.
Note that in the previous release, calling getSecondaryIndex in such a
situation would fail, and it was necessary to call registerClass as a
workaround. [#15102]
-
A bug was fixed that caused an IllegalArgumentException with the
message "Not a key class". This occurred when using a TO_MANY
secondary index with a composite key class. The workaround for the
bug was to call registerClass for the key class, and this is no longer
necessary. [#15103]
-
An optional verbose option was added to the ClassEnhancer to print the
name of each class file that is enhanced. See ClassEnhancer for more
information.
[#14680](3.0.12)
-
Class evolution is now implemented in the Direct Persistence Layer.
For more information please see the release notes and the package
specification for the com.sleepycat.persist.evolve package. Also note
that if you have deployed a store using the JE 3.0.12 beta release,
before changing your persistent classes for the first time you must
open and close your store using the JE 3.1 release; see the release
notes for more information. [#14762](3.1.0)
-
Fixed a bug that prevented opening a read-only store when a primary
key sequence was used. [#14941](3.1.0)
- Fixed a bug that prevented using EntityJoin with read-uncommitted
(for example, CursorConfig.READ_UNCOMMITTED). The fix is a change to
JE secondary databases that allows a partial DatabaseEntry to be
passed as the data parameter to a search method, when using
read-uncommitted. [#14966](3.1.0)
-
Fixed a bug in EntityStore.getStoreNames() which resulted in this stack trace:
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 that caused an IllegalArgumentException when calling
EntityStore.getSecondaryIndex for a @SecondaryKey that was declared on
a superclass of the entity class. [#14978](3.1.0)
-
The EntityStore.getSubclassIndex method has been added. This method
should be used instead of getSecondaryIndex when the secondary key
field is in a subclass of an entity class. The index returned by
getSubclassIndex is used to access only entities of that subclass.
Note that in the previous release, calling getSecondaryIndex in such a
situation would fail, and it was necessary to call registerClass as a
workaround. [#15102](3.1.0)
-
A bug was fixed that caused an IllegalArgumentException with the
message "Not a key class". This occurred when using a TO_MANY
secondary index with a composite key class. The workaround for the
bug was to call registerClass for the key class, and this is no longer
necessary. [#15103](3.1.0)
-
Fixed a bug where the wrong key class was validated when calling
EntityStore.getSecondaryIndex for a read-only store with a TO_MANY secondary.
The application would see an IllegalArgumentException prefixed with "Wrong
secondary key class:". [#15156] (3.2.13)
-
Fixed a bug where the DPL was not working correctly with implicit transactions
in an XA environment. The problem was reported in this JE
Forum thread.. Now, when an XAEnvironment is used, XA transactions are
implicit when a null transaction parameter, or no transaction parameter, is
used in the DPL API. [#15206] (3.2.13)
-
Fixed a potential performance problem with secondary indexes that are defined
in entity subclasses. When an instance of an entity subclass is stored (via
PrimaryIndex.put), we now create any secondary indexes that are defined on that
subclass. Before, the secondary indexes were not created until
EntityStore.getSubclassIndex was called. This was not technically a bug, since
there was no loss of data and secondary indexes were created when they were
used. But now the index is created as soon as possible, so that the index does
not have to populated from scratch when it is first accessed. [#15247] (3.2.13)
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:
-
First take a directory listing of your Environment and examine all the
*.jdb files written at the time of the attempted upgrade. For example:
-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
-
Examine all the new files to verify that they use file version 4 by doing:
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: