Changes since Release 2.0.90
For additional details, please see the documentation and Release Notes included in your download package or on our website.
je.cleaner.threadsproperty is used to configure the number of threads. The default is one thread.
je.cleaner.lookAheadCacheSizeproperty. The default value is 8 KB.
removeDatabase()are significantly faster. [#13333] (2.1.30)
je.cleaner.minFileUtilizationproperty. [#13335] (2.1.30)
NullPointerExceptionwhen getDatabaseNames is called and the first database (name order wise) has been renamed or removed. [#13377] (2.1.30)
Cursor.getSearchBothRange() did not properly match the documentation. In the past a range search was done on the key as well as the data value when finding a record to return. This has been fixed so that an exact match is required for the key, and a range search is done for the data. [#13388] (2.1.30)
com.sleepycat.je.tree.InconsistentNodeExceptioncould be thrown at environment instantiation for applications which use records with duplicate keys, and periodically delete the entire duplicate set (of records with the same key). [#13501] (2.1.30)
Cursor.count()to return the wrong count for a set of duplicate records. The count would be off by 1. [#13726] (2.1.30)
je.forceJVMArchto either "32" or "64". The JVM version determination uses the same logic employed by [#13227] for choosing to use Java 1.5 synchronization, and can be overridden using the property
je.disable.java5.latches. [#13865] (2.1.30)
com.sleepycat.je.dbi.CursorImpl.cloneCursor(). [#13879] (2.1.30);
ClassCastExceptionduring record locking with instanceof. This could be confusing for users who had set a breakpoint on
ClassCastExceptionand was also slower than using instanceof. [#13913] (2.1.30)
je.txn.deadlockStackTraceproperty to allow getting a stack trace in deadlock exception messages without having to modify JE sources. Added the
je.txn.dumpLocksproperty to dump the entire lock table in a deadlock exception message, for debugging. The output of the entire lock table can be large, but is useful for determining the locking relationships between records. [#13377] (2.1.30)
je.env.fairLatchesis now a static property (i.e. it is the same across all environments and the value is that of the last environment opened. A new property,
je.disable.java5.latcheswill force loading old style latches if set. One use case might be an application that wants to configure latches with interruptibility. Java 5 latches are by default not interruptible, and the JE proprietary implementation is both interruptible and faster than Java 5 locking with interruptibility set, so in such a use case the most optimal choice is to use je.disable.java5.latches property to force traditional JE latches to be loaded.(2.1.30)
je.lock.nLockTableswas added to specify the number of lock tables. While the default is 1, increasing this number can improve multithreaded concurrency. The value of this property should be a prime number, and should ideally be the nearest prime that is not greater than the number of concurrent threads. [#13587] (2.1.30)
No-locking mode is controlled by
EnvironmentConfig.setLocking(boolean). The default is true (locking is enabled). Locking cannot be disabled in a transactional environment. [#13788] (2.1.30)
Database.preload()is significantly faster, returns statistics on preload activity, and can be configured to preload data records as well as internal database nodes. The signature has been changed to
Preload Stats preload(PreloadConfig), and older forms of preload() are deprecated.
preload() now returns a
PreloadStats object which contains status (success, time_exceeded, or cache_exceeded) and stats (# LNs, BINs, INs, etc. loaded). It now takes
PreloadConfig as argument to specify maxBytes, maxMillisecs, and whether to load LN's or not. (2.1.30)
java -jar je.jar DbDump <args>instead of specifying the full class name. [#13469] (2.1.30)