The changes between 3.2.76 and 3.3.62 are described directly below.
The change is forward compatible in that JE files created with release 3.2.* and earlier can be read when opened with JE 3.3.62. The change is not backward compatible in that files created with JE 3.3.62 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.3.62 and the environment can no longer be read by earlier releases.
A number of these on-disk format changes were made to reduce disk-space usage. [#15399]
Also note the binary and compile time incompatibilities between JE 3.3 and JE 3.2 described in the API Changes section.
In addition, two internal changes have been made to durable deferred-write database behavior. These changes are compatible with the existing use of deferred-write database, but may influence performance characteristics. These changes were necessary to ensure that the log cleaner operates properly for deferred-write databases.
return operation and byte counts for the number of random and sequential disk IOs. All values are approximate and may differ from the actual number of operations/byte-counts depending on the type of disks and file system, disk geometry, and file system cache size. [#16086]
EnvironmentStats.getNRandomReads() EnvironmentStats.getNRandomWrites() EnvironmentStats.getNRandomReadBytes() EnvironmentStats.getNRandomWriteBytes() EnvironmentStats.getNSequentialReads() EnvironmentStats.getNSequentialWrites() EnvironmentStats.getNSequentialReadBytes() EnvironmentStats.getNSequentialWriteBytes()
EnvironmentStats.getNFileOpens()can indicate a need to tune the size of the file handle cache through increasing the
je.log.fileCacheSizeproperty. Also, general improvements have been made to improve the file handle cache, and to remove a bottleneck in concurrency in that area. [#16166]
If the application used a custom comparator defined as
DatabaseConfig.setBtreeComparator(Class<? extends Comparator<byte>>)
DatabaseConfig.setDuplicateComparator(Class<? extends Comparator<byte>>)
public class MyCompare implements Comparator, Serializablethat should now be declared as
public class MyCompare implements Comparator<byte>, SerializablePlease note that while these are fine:
Comparator<byte> compareInstance = new MyCompare(); dbConfig.setBtreeComparator(compareInstance);or
dbConfig.setBtreeComparator(MyCompare.class);the following previously legal line will now provoke a compile error:
dbConfig.setBtreeComparator(compareInstance.getClass());The compile error is puzzling and regrettably breaks compile time compatibility with JE 3.2 and earlier, but comes about because in Java, due to its type erasure based generics scheme, all the instances of a generic class have the same runtime class. Instead, the application has to apply the following cast:
dbConfig.setBtreeComparator((Class<? extends Comparator<byte>>) compareInstance.getClass());