Upgrade to JE 3.2.29.

Changes since 3.2.21
Log File On-Disk Format Changes:
None.
New Features:
None.
General Environment Changes

   1. Fixed a bug that causes a memory leak for applications when many Environment objects are opened and closed and the CurrentTransaction or TransactionRunner class is used. The problem was reported in this JE Forum thread [#15444]

   2. Fixed a bug that prevents correct recovery of data records when duplicates are configured (DatabaseConfig.setSortedDuplicates(true)) for a deferred-write database (DatabaseConfig.setDeferredWrite(true)). When a crash occurs and duplicate data records are recovered that were flushed after the last checkpoint, the wrong key is used for those records. This bug does not occur when the environment is closed normally or a checkpoint is performed after writing data records. [#15474]

   3. Fixed a bug that prevents Database.preload from working when duplicates are configured (DatabaseConfig.setSortedDuplicates(true)) for the database. When the preload method was called for a database for which duplicate records exist, an assertion would fire or a NullPointerException would be thrown, depending on whether assertions are enabled. [#15475]

   4. Enhanced SerialBinding and the Direct Persistence Layer to use the current thread's context class loader when loading application classes. This allows the JE jar file to be deployed in application servers and other containers as a shared library rather than as an application jar. [#15447]

   5. Fixed a bug that caused JE to incorrectly behave as if the cache was very full. The symptoms of this bug are:
          * Because the problem is a cumulative accounting error, symptoms appear after running for a long period of time.
          * JE slows down or methods fail to return. Thread dumps show that the com.sleepycat.je.evictor.Evictor class is active and looping.
          * Dumping EnvironmentStats shows that the adminBytes size (EnvironmentStats.getAdminBytes()) is unreasonably large and may be larger than the maximum cache size or the heap size.
          * The problem occurs more frequently when blocks of sequential records are deleted.
      [#15505]

   6. Fixed a bug where the cache usage accounting could become inaccurate if the cache size was changed while the application is active (using Environment.setMutableConfig()) and there are outstanding record locks. [#15505]

   7. Fixed a bug that caused incorrect query results, and possibly errors during recovery, when a custom duplicate comparison method is configured and that method does not compare all bytes of its operands. A custom comparator should always compare all bytes of its operands and should return non-zero if they are unequal. When updating existing records, JE will detect this kind of incorrect comparator in order to prevent database inconsistency. The problem was reported in this JE Forum thread. [#15527]

Direct Persistence Layer (DPL)
None.
API Changes:

   1. Added the EnvironmentStats.getAdminBytes() and getLockBytes() methods, which return the amount of cache used for transactions, administrative structures such as log cleaning metadata, and locks. These values are a subset of the value returned by Environment.getCacheDataBytes() and can provide more insight into how the cache is allocated between actual data and other objects. [#15505]

   2. Added the EnvironmentStats.getTotalLogSize method. This new method returns the approximate total size of the JE log files in bytes. It could be used, for example, to detect that the log has exceeded an application disk space limit. [#15480]

Utility Changes:
None.
Configuration, Documentation, Test and Build Changes:
None.