Berkeley DB Java Edition 3.2.23 Change Log
The changes between 3.2.13 and 3.2.23 are described directly
below. A full list of all changes since JE 2.1.34 is also available below.
Changes since 3.2.21
Log File On-Disk Format Changes:
None.
New Features:
None.
General Environment Changes
- Fixed a bug which allowed operations other than commit() and
rollback() to occur on XAEnvironment instances which had been
"prepared". Changed the XAEnvironment.prepare() method to return
XA_RDONLY for read-only transactions. The problem was initially
reported on this JE
Forum thread. [#15423]
- Fixed a rare case in which an Error (for example, a
java.lang.OutOfMemoryError) is caught and can trigger a transaction
abort, but fails to invalidate the environment. Since OutOfMemoryError
can result in unpredictable behavior upon subsequent I/O activity, JE's
general choice of action is to invalidate the environment and throw
RunRecoveryException on all subsequent operations. Although this is not
proven, it seems possible that this failure to invalidate the
environment could lead to data corruption, so this bug fix, although
small in scope, is deemed critical. [#15417]
Direct Persistence Layer (DPL)
None.
API Changes:
None.
Utility Changes:
None.
Configuration, Documentation, Test and Build Changes:
None.
All changes from JE 3.0.11, 3.0.12, 3.1.0, 3.2.13,
3.2.21 and 3.2.23 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)
- Fixed a bug where an exception similar to the following
exception could occur after calling Environment.removeDatabase() for a
deferred write database for which Database.sync() was never called.
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)
- Fixed a bug where a mutex deadlock could occur under low
memory conditions. [#15176] (3.2.21)
- Fixed a bug where use of XAEnvironment and a non 8-bit
encoding could cause BufferOverflowExceptions during recovery. The
following stack trace shows the problem.
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)
- Fixed a bug in JE debugging code that caused an assertion to
fire when running with opening and closing multiple environments with
assertions enabled. The stack trace would look something like this:
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)
- Fixed a race condition at Environment startup which could
result in a deadlock between the Cleaner thread and the thread
instantiating the Environment object. This problem can only occur with
pre-existing environments. The thread that is calling new Environment()
will hang with a stack trace similar to this:
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)
- Fixed a bug regarding databases which support sorted
duplicates where the wrong key comparator can be used in certain cases
by the compressor daemon. The problem results in some wasted work for
the compressor daemon, and the possibility that a user specified custom
duplicate comparator is called with the wrong type of data, but will
not affect database correctness or database operations. This problem
was reported in this JE
forum thread. [#15317] (3.2.21)
- Fixed a problem with log cleaning and deferred write
databases. Before, log files were often not cleaned when data in
deferred write databases overflowed to disk, was modified, and became
obsolete. This problem has been corrected; however, to ensure log
cleaning occurs you must either 1) call Database.sync before
Database.close, or 2) call Environment.removeDatabase before
Environment.close() [#15391] (3.2.21)
- Fixed a bug which in rare cases caused a DatabaseException
with the message "NULL_LSN without KnownDeleted" during recovery when
opening an Environment read-only, following an abnormal shutdown.
[#15397] (3.2.21)
- Fixed a bug which resulted in a NullPointerException when
Environment.close() is called with java.util.logging.level set to FINE.
This problem was reported in this JE
forum thread. (3.2.21)
- Fixed a bug which allowed operations other than commit() and
rollback() to occur on XAEnvironment instances which had been
"prepared". Changed the XAEnvironment.prepare() method to return
XA_RDONLY for read-only transactions. The problem was initially
reported on this JE
Forum thread. [#15423] (3.2.23)
- Fixed a rare case in which an Error (for example, a
java.lang.OutOfMemoryError) is caught and can trigger a transaction
abort, but fails to invalidate the environment. Since OutOfMemoryError
can result in unpredictable behavior upon subsequent I/O activity, JE's
general choice of action is to invalidate the environment and throw
RunRecoveryException on all subsequent operations. Although this is not
proven, it seems possible that this failure to invalidate the
environment could lead to data corruption, so this bug fix, although
small in scope, is deemed critical. [#15417](3.2.23)
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)
- Added je.evictor.forcedYield to improve GC behavior for
systems with unfair thread scheduling and/or many environments open.
[#15329] (3.2.21)
- The Collections API has been enhanced so that auto-commit
works for the standard Java Iterator.remove(), set() and add() methods.
Previously it was necessary to explicitly begin and commit a
transaction in order to call these methods, when the underlying
Database was transactional. Note that starting a transaction is still
necessary when calling these methods if the
StoredCollection.storedIterator method is used. [#15401] (3.2.21)
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: