EnvironmentConfig (Oracle - Berkeley DB Java Edition API)

java.lang.Object
- com.sleepycat.je.EnvironmentMutableConfig
- - com.sleepycat.je.EnvironmentConfig

All Implemented Interfaces:: java.io.Serializable, java.lang.Cloneable

public class EnvironmentConfig
extends EnvironmentMutableConfig

Specifies the attributes of an environment.

To change the default settings for a database environment, an application creates a configuration object, customizes settings and uses it for environment construction. The set methods of this class validate the configuration values when the method is invoked. An IllegalArgumentException is thrown if the value is not valid for that attribute.

Most parameters are described by the parameter name String constants in this class. These parameters can be specified or individually by calling setConfigParam(java.lang.String, java.lang.String), through a Properties object passed to EnvironmentConfig(Properties), or via properties in the je.properties files located in the environment home directory.

For example, an application can change the default btree node size with:

     envConfig.setConfigParam(EnvironmentConfig.LOCK_TIMEOUT, "250 ms");

Some commonly used environment attributes have convenience setter/getter methods defined in this class. For example, to change the default lock timeout setting for an environment, the application can instead do the following:

     // customize an environment configuration
     EnvironmentConfig envConfig = new EnvironmentConfig();
     // will throw if timeout value is invalid
     envConfig.setLockTimeout(250, TimeUnit.MILLISECONDS);
     // Open the environment using this configuration.
     Environment myEnvironment = new Environment(home, envConfig);

Parameter values are applied using this order of precedence:

Configuration parameters specified in je.properties take first precedence.
Configuration parameters set in the EnvironmentConfig object used at Environment construction are next.
Any configuration parameters not set by the application are set to system defaults, described along with the parameter name String constants in this class.

However, a small number of parameters do not have string constants in this class, and cannot be set using setConfigParam(java.lang.String, java.lang.String), a Properties object, or the je.properties file. These parameters can only be changed via the following setter methods:

An EnvironmentConfig can be used to specify both mutable and immutable environment properties. Immutable properties may be specified when the first Environment handle (instance) is opened for a given physical environment. When more handles are opened for the same environment, the following rules apply:

Immutable properties must equal the original values specified when constructing an Environment handle for an already open environment. When a mismatch occurs, an exception is thrown.
Mutable properties are ignored when constructing an Environment handle for an already open environment.

After an Environment has been constructed, its mutable properties may be changed using Environment.setMutableConfig(com.sleepycat.je.EnvironmentMutableConfig). See EnvironmentMutableConfig for a list of mutable properties; all other properties are immutable. Whether a property is mutable or immutable is also described along with the parameter name String constants in this class.

Getting the Current Environment Properties

To get the current "live" properties of an environment after constructing it or changing its properties, you must call Environment.getConfig() or Environment.getMutableConfig(). The original EnvironmentConfig or EnvironmentMutableConfig object used to set the properties is not kept up to date as properties are changed, and does not reflect property validation or properties that are computed.

Time Duration Properties

Several environment and transaction configuration properties are time durations. For these properties, a time unit is specified along with an integer duration value.

When specific setter and getter methods exist for a time duration property, these methods have a TimeUnit argument. Examples are setLockTimeout(long,TimeUnit) and getLockTimeout(TimeUnit). Note that the TimeUnit argument may be null only when the duration value is zero; there is no default unit that is used when null is specified.

When a time duration is specified as a string value, the following format is used.

    <value> [ <whitespace> <unit> ]

The <value> is an integer. The <unit> name, if present, must be preceded by one or more spaces or tabs.

The following <unit> names are allowed. Both TimeUnit names and IEEE standard abbreviations are allowed. Unit names are case insensitive.

IEEE abbreviation	TimeUnit name	Definition
`ns`	`NANOSECONDS`	one billionth (10^-9) of a second
`us`	`MICROSECONDS`	one millionth (10^-6) of a second
`ms`	`MILLISECONDS`	one thousandth (10^-3) of a second
`s`	`SECONDS`	1 second
`min`		60 seconds
`h`		3600 seconds

Examples are:

 3 seconds
 3 s
 500 ms
 1000000 (microseconds is implied)

The maximum duration value is currently Integer.MAX_VALUE milliseconds. This translates to almost 25 days (2147483647999999 ns, 2147483647999 us, 2147483647 ms, 2147483 s, 35791 min, 596 h).

Note that when the <unit> is omitted, microseconds is implied. This default is supported for compatibility with JE 3.3 and earlier. In JE 3.3 and earlier, explicit time units were not used and durations were always implicitly specified in microseconds. The older methods that do not have a TimeUnit argument, such as setLockTimeout(long) and getLockTimeout(), use microsecond durations and have been deprecated.

See Also:: Serialized Form

Field Summary

Fields
Modifier and Type	Field and Description
`static java.lang.String`	`ADLER32_CHUNK_SIZE` By default, JE passes an entire log record to the Adler32 class for checksumming.
`static java.lang.String`	`CHECKPOINTER_BYTES_INTERVAL` Ask the checkpointer to run every time we write this many bytes to the log.
`static java.lang.String`	`CHECKPOINTER_DEADLOCK_RETRY` The number of times to retry a checkpoint if it runs into a deadlock.
`static java.lang.String`	`CHECKPOINTER_HIGH_PRIORITY` If true, the checkpointer uses more resources in order to complete the checkpoint in a shorter time interval.
`static java.lang.String`	`CHECKPOINTER_WAKEUP_INTERVAL` The checkpointer wakeup interval in microseconds.
`static java.lang.String`	`CLEANER_ADJUST_UTILIZATION` Deprecated. in JE 6.3. Adjustments are no longer needed because LN log sizes have been stored in the Btree since JE 6.0.
`static java.lang.String`	`CLEANER_BACKGROUND_PROACTIVE_MIGRATION` Deprecated. This parameter is ignored and proactive migration is no longer supported due to its negative impact on eviction and checkpointing. To reduce a cleaner backlog, configure more cleaner threads.
`static java.lang.String`	`CLEANER_BYTES_INTERVAL` The cleaner checks disk utilization every time we write this many bytes to the log.
`static java.lang.String`	`CLEANER_DEADLOCK_RETRY` The number of times to retry cleaning if a deadlock occurs.
`static java.lang.String`	`CLEANER_DETAIL_MAX_MEMORY_PERCENTAGE` Tracking of detailed cleaning information will use no more than this percentage of the cache.
`static java.lang.String`	`CLEANER_EXPUNGE` If true (the default setting), the cleaner deletes log files after successful cleaning.
`static java.lang.String`	`CLEANER_FETCH_OBSOLETE_SIZE` If true, the cleaner will fetch records to determine their size and more accurately calculate log utilization.
`static java.lang.String`	`CLEANER_FORCE_CLEAN_FILES` Specifies a list of files or file ranges to be cleaned at a time when no other log cleaning is necessary.
`static java.lang.String`	`CLEANER_FOREGROUND_PROACTIVE_MIGRATION` Deprecated. This parameter is ignored and proactive migration is no longer supported due to its negative impact on eviction and Btree splits. To reduce a cleaner backlog, configure more cleaner threads.
`static java.lang.String`	`CLEANER_LAZY_MIGRATION` Deprecated. This parameter is ignored and lazy migration is no longer supported due to its negative impact on eviction and checkpointing. To reduce a cleaner backlog, configure more cleaner threads.
`static java.lang.String`	`CLEANER_LOCK_TIMEOUT` The lock timeout for cleaner transactions in microseconds.
`static java.lang.String`	`CLEANER_LOOK_AHEAD_CACHE_SIZE` The look ahead cache size for cleaning in bytes.
`static java.lang.String`	`CLEANER_MAX_BATCH_FILES` Deprecated. in 7.0. No longer used because the cleaner no longer has a backlog.
`static java.lang.String`	`CLEANER_MIN_AGE` The minimum age of a file (number of files between it and the active file) to qualify it for cleaning under any conditions.
`static java.lang.String`	`CLEANER_MIN_FILE_UTILIZATION` A log file will be cleaned if its utilization percentage is below this value, irrespective of total utilization.
`static java.lang.String`	`CLEANER_MIN_UTILIZATION` The cleaner will keep the total disk space utilization percentage above this value.
`static java.lang.String`	`CLEANER_READ_SIZE` The read buffer size for cleaning.
`static java.lang.String`	`CLEANER_THREADS` The number of threads allocated by the cleaner for log file processing.
`static java.lang.String`	`CLEANER_UPGRADE_TO_LOG_VERSION` All log files having a log version prior to the specified version will be cleaned at a time when no other log cleaning is necessary.
`static java.lang.String`	`CLEANER_USE_DELETED_DIR` When `CLEANER_EXPUNGE` is false, the `CLEANER_USE_DELETED_DIR` parameter determines whether successfully cleaned files are moved to the "deleted" sub-directory.
`static java.lang.String`	`CLEANER_WAKEUP_INTERVAL` The cleaner checks whether cleaning is needed if this interval elapses without any writing, to handle the case where cleaning or checkpointing is necessary to reclaim disk space, but writing has stopped.
`static java.lang.String`	`COMPRESSOR_DEADLOCK_RETRY` The number of times to retry a compression run if a deadlock occurs.
`static java.lang.String`	`COMPRESSOR_LOCK_TIMEOUT` The lock timeout for compressor transactions in microseconds.
`static java.lang.String`	`COMPRESSOR_PURGE_ROOT` Deprecated. as of 3.3.87. Compression of the root node no longer has any benefit and this feature has been removed. This parameter has no effect.
`static java.lang.String`	`COMPRESSOR_WAKEUP_INTERVAL` The compressor thread wakeup interval in microseconds.
`static java.lang.String`	`CONSOLE_LOGGING_LEVEL` Trace messages equal and above this level will be logged to the console.
`static java.lang.String`	`DOS_PRODUCER_QUEUE_TIMEOUT` The timeout for Disk Ordered Scan producer thread queue offers in milliseconds.
`static java.lang.String`	`ENV_BACKGROUND_READ_LIMIT` The maximum number of read operations performed by JE background activities (e.g., cleaning) before sleeping to ensure that application threads can perform I/O.
`static java.lang.String`	`ENV_BACKGROUND_SLEEP_INTERVAL` The duration that JE background activities will sleep when the `ENV_BACKGROUND_WRITE_LIMIT` or `ENV_BACKGROUND_READ_LIMIT` is reached.
`static java.lang.String`	`ENV_BACKGROUND_WRITE_LIMIT` The maximum number of write operations performed by JE background activities (e.g., checkpointing and eviction) before sleeping to ensure that application threads can perform I/O.
`static java.lang.String`	`ENV_CHECK_LEAKS` Debugging support: check leaked locks and txns at env close.
`static java.lang.String`	`ENV_DB_EVICTION` If true, enable eviction of metadata for closed databases.
`static java.lang.String`	`ENV_DUP_CONVERT_PRELOAD_ALL` If true (the default) preload all duplicates databases at once when upgrading from JE 4.1 and earlier.
`static java.lang.String`	`ENV_EXPIRATION_ENABLED` If true (the default), expired data is filtered from queries and purged by the cleaner.
`static java.lang.String`	`ENV_FAIR_LATCHES` If true, use latches instead of synchronized blocks to implement the lock table and log write mutexes.
`static java.lang.String`	`ENV_FORCED_YIELD` Debugging support: call Thread.yield() at strategic points.
`static java.lang.String`	`ENV_IS_LOCKING` Configures the database environment for no locking.
`static java.lang.String`	`ENV_IS_TRANSACTIONAL` Configures the use of transactions.
`static java.lang.String`	`ENV_LATCH_TIMEOUT` The timeout for detecting internal latch timeouts, so that deadlocks can be detected.
`static java.lang.String`	`ENV_READ_ONLY` Configures the database environment to be read-only, and any attempt to modify a database will fail.
`static java.lang.String`	`ENV_RECOVERY_FORCE_CHECKPOINT` If true, a checkpoint is forced following recovery, even if the log ends with a checkpoint.
`static java.lang.String`	`ENV_RECOVERY_FORCE_NEW_FILE` Used after performing a restore from backup to force creation of a new log file prior to recovery.
`static java.lang.String`	`ENV_RUN_CHECKPOINTER` If true, starts up the checkpointer thread.
`static java.lang.String`	`ENV_RUN_CLEANER` If true, starts up the cleaner thread.
`static java.lang.String`	`ENV_RUN_EVICTOR` If true, eviction is done by a pool of evictor threads, as well as being done inline by application threads.
`static java.lang.String`	`ENV_RUN_IN_COMPRESSOR` If true, starts up the INCompressor thread.
`static java.lang.String`	`ENV_RUN_OFFHEAP_EVICTOR` If true, off-heap eviction is done by a pool of evictor threads, as well as being done inline by application threads.
`static java.lang.String`	`ENV_RUN_VERIFIER` Whether to run the background verifier.
`static java.lang.String`	`ENV_TTL_CLOCK_TOLERANCE` The interval added to the system clock time for determining that a record may have expired.
`static java.lang.String`	`EVICTOR_ALLOW_BIN_DELTAS` Allow Bottom Internal Nodes (BINs) to be written in a delta format during eviction.
`static java.lang.String`	`EVICTOR_CORE_THREADS` The minimum number of threads in the eviction thread pool.
`static java.lang.String`	`EVICTOR_CRITICAL_PERCENTAGE` At this percentage over the allotted cache, critical eviction will start.
`static java.lang.String`	`EVICTOR_DEADLOCK_RETRY` Deprecated. as of JE 4.1, since the single evictor thread has been replaced be a more robust thread pool.
`static java.lang.String`	`EVICTOR_EVICT_BYTES` When eviction occurs, the evictor will push memory usage to this number of bytes below `MAX_MEMORY`.
`static java.lang.String`	`EVICTOR_FORCED_YIELD` Call Thread.yield() at each check for cache overflow.
`static java.lang.String`	`EVICTOR_KEEP_ALIVE` The duration that excess threads in the eviction thread pool will stay idle; after this period, idle threads will terminate.
`static java.lang.String`	`EVICTOR_LRU_ONLY` Deprecated. as of JE 6.0. This parameter is ignored by the new, more efficient and more accurate evictor.
`static java.lang.String`	`EVICTOR_MAX_THREADS` The maximum number of threads in the eviction thread pool.
`static java.lang.String`	`EVICTOR_N_LRU_LISTS` The number of LRU lists in the main JE cache.
`static java.lang.String`	`EVICTOR_NODES_PER_SCAN` Deprecated. as of JE 6.0. This parameter is ignored by the new, more efficient and more accurate evictor.
`static java.lang.String`	`FILE_LOGGING_LEVEL` Trace messages equal and above this level will be logged to the je.info file, which is in the Environment home directory.
`static java.lang.String`	`FREE_DISK` A lower limit on the number of bytes of free space to maintain on a volume and per JE Environment.
`static java.lang.String`	`HALT_ON_COMMIT_AFTER_CHECKSUMEXCEPTION` By default, if a checksum exception is found at the end of the log during Environment startup, JE will assume the checksum is due to previously interrupted I/O and will quietly truncate the log and restart.
`static java.lang.String`	`LOCK_DEADLOCK_DETECT` Whether to perform deadlock detection when a lock conflict occurs.
`static java.lang.String`	`LOCK_DEADLOCK_DETECT_DELAY` The delay after a lock conflict, before performing deadlock detection.
`static java.lang.String`	`LOCK_N_LOCK_TABLES` Number of Lock Tables.
`static java.lang.String`	`LOCK_OLD_LOCK_EXCEPTIONS` Deprecated. since JE 6.5; has no effect, as if it were set to false.
`static java.lang.String`	`LOCK_TIMEOUT` Configures the default lock timeout.
`static java.lang.String`	`LOG_BUFFER_SIZE` The maximum starting size of a JE log buffer.
`static java.lang.String`	`LOG_CHECKSUM_READ` If true, perform a checksum check when reading entries from log.
`static java.lang.String`	`LOG_CHUNKED_NIO` Deprecated. NIO is no longer used by JE and this parameter has no effect.
`static java.lang.String`	`LOG_DETECT_FILE_DELETE` If true, periodically detect unexpected file deletions.
`static java.lang.String`	`LOG_DETECT_FILE_DELETE_INTERVAL` The interval used to check for unexpected file deletions.
`static java.lang.String`	`LOG_DIRECT_NIO` Deprecated. NIO is no longer used by JE and this parameter has no effect.
`static java.lang.String`	`LOG_FAULT_READ_SIZE` The buffer size for faulting in objects from disk, in bytes.
`static java.lang.String`	`LOG_FILE_CACHE_SIZE` The size of the file handle cache.
`static java.lang.String`	`LOG_FILE_MAX` The maximum size of each individual JE log file, in bytes.
`static java.lang.String`	`LOG_FLUSH_NO_SYNC_INTERVAL` The maximum time interval between committing a transaction with `NO_SYNC` durability, and making the transaction durable with respect to the file system.
`static java.lang.String`	`LOG_FLUSH_SYNC_INTERVAL` The maximum time interval between committing a transaction with `NO_SYNC` or `WRITE_NO_SYNC` durability, and making the transaction durable with respect to the storage device.
`static java.lang.String`	`LOG_FSYNC_TIME_LIMIT` If the time taken by an fsync exceeds this limit, a WARNING level message is logged.
`static java.lang.String`	`LOG_FSYNC_TIMEOUT` The timeout limit for group file sync, in microseconds.
`static java.lang.String`	`LOG_GROUP_COMMIT_INTERVAL` The time interval in nanoseconds during which transactions may be grouped to amortize the cost of write and/or fsync when a transaction commits with SyncPolicy#SYNC or SyncPolicy#WRITE_NO_SYNC on the local machine.
`static java.lang.String`	`LOG_GROUP_COMMIT_THRESHOLD` The threshold value impacts the number of transactions that may be grouped to amortize the cost of write and/or fsync when a transaction commits with SyncPolicy#SYNC or SyncPolicy#WRITE_NO_SYNC on the local machine.
`static java.lang.String`	`LOG_ITERATOR_MAX_SIZE` The maximum read buffer size for log iterators, which are used when scanning the log during activities like log cleaning and environment open, in bytes.
`static java.lang.String`	`LOG_ITERATOR_READ_SIZE` The read buffer size for log iterators, which are used when scanning the log during activities like log cleaning and environment open, in bytes.
`static java.lang.String`	`LOG_MEM_ONLY` If true, operates in an in-memory test mode without flushing the log to disk.
`static java.lang.String`	`LOG_N_DATA_DIRECTORIES` Deprecated. as of 7.3. This feature is not known to provide benefits beyond that of a simple RAID configuration, and will be removed in the next release, which is slated for mid-April, 2017.
`static java.lang.String`	`LOG_NUM_BUFFERS` The number of JE log buffers.
`static java.lang.String`	`LOG_TOTAL_BUFFER_BYTES` The total memory taken by log buffers, in bytes.
`static java.lang.String`	`LOG_USE_NIO` Deprecated. NIO is no longer used by JE and this parameter has no effect.
`static java.lang.String`	`LOG_USE_ODSYNC` If true (default is false) O_DSYNC is used to open JE log files.
`static java.lang.String`	`LOG_USE_WRITE_QUEUE` If true (default is true) the Write Queue is used for file I/O operations which are blocked by concurrent I/O operations.
`static java.lang.String`	`LOG_VERIFY_CHECKSUMS` If true, perform a checksum verification just before and after writing to the log.
`static java.lang.String`	`LOG_WRITE_QUEUE_SIZE` The size of the Write Queue.
`static java.lang.String`	`MAX_DISK` An upper limit on the number of bytes used for data storage.
`static java.lang.String`	`MAX_MEMORY` Configures the JE main cache size in bytes.
`static java.lang.String`	`MAX_MEMORY_PERCENT` Configures the JE main cache size as a percentage of the JVM maximum memory.
`static java.lang.String`	`MAX_OFF_HEAP_MEMORY` Configures the number of bytes to be used as a secondary, off-heap cache.
`static java.lang.String`	`NODE_DUP_TREE_MAX_ENTRIES` Deprecated. this property no longer has any effect; `DatabaseConfig.setNodeMaxEntries(int)` should be used instead.
`static java.lang.String`	`NODE_MAX_ENTRIES` The maximum number of entries in an internal btree node.
`static java.lang.String`	`OFFHEAP_CHECKSUM` Can be used to add a checksum to each off-heap block when the block is written, and validate the checksum when the block is read, for debugging purposes.
`static java.lang.String`	`OFFHEAP_CORE_THREADS` The minimum number of threads in the off-heap eviction thread pool.
`static java.lang.String`	`OFFHEAP_EVICT_BYTES` The off-heap evictor will attempt to keep memory usage this number of bytes below `MAX_OFF_HEAP_MEMORY`.
`static java.lang.String`	`OFFHEAP_KEEP_ALIVE` The duration that excess threads in the off-heap eviction thread pool will stay idle; after this period, idle threads will terminate.
`static java.lang.String`	`OFFHEAP_MAX_THREADS` The maximum number of threads in the off-heap eviction thread pool.
`static java.lang.String`	`OFFHEAP_N_LRU_LISTS` The number of LRU lists in the off-heap JE cache.
`static java.lang.String`	`SHARED_CACHE` If true, the shared cache is used by this environment.
`static java.lang.String`	`STARTUP_DUMP_THRESHOLD` If environment startup exceeds this duration, startup statistics are logged and can be found in the je.info file.
`static java.lang.String`	`STATS_COLLECT` If true collect and log statistics.
`static java.lang.String`	`STATS_COLLECT_INTERVAL` The duration of the statistics capture interval.
`static java.lang.String`	`STATS_FILE_DIRECTORY` The directory to save the statistics log file.
`static java.lang.String`	`STATS_FILE_ROW_COUNT` Log file maximum row count for Stat collection.
`static java.lang.String`	`STATS_MAX_FILES` Maximum number of statistics log files to retain.
`static java.lang.String`	`TRACE_CONSOLE` Deprecated. in favor of `CONSOLE_LOGGING_LEVEL` As of JE 4.0, use the standard java.util.logging configuration methodologies. To enable console output, set com.sleepycat.je.util.ConsoleHandler.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager. To set the handler level programmatically, set "com.sleepycat.je.util.ConsoleHandler.level" in the EnvironmentConfig object.
`static java.lang.String`	`TRACE_DB` Deprecated. As of JE 4.0, event tracing to the .jdb files has been separated from the java.util.logging mechanism. This parameter has no effect.
`static java.lang.String`	`TRACE_FILE` Deprecated. in favor of `FILE_LOGGING_LEVEL` As of JE 4.0, use the standard java.util.logging configuration methodologies. To enable logging output to the je.info files, set com.sleepycat.je.util.FileHandler.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager. To set the handler level programmatically, set "com.sleepycat.je.util.FileHandler.level" in the EnvironmentConfig object.
`static java.lang.String`	`TRACE_FILE_COUNT` Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To set the FileHandler output file count, set com.sleepycat.je.util.FileHandler.count = <NUMBER> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
`static java.lang.String`	`TRACE_FILE_LIMIT` Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To set the FileHandler output file size, set com.sleepycat.je.util.FileHandler.limit = <NUMBER> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
`static java.lang.String`	`TRACE_LEVEL` Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. Set logging levels using class names through the java.util.logging configuration file, or through the java.util.logging.LogManager.
`static java.lang.String`	`TRACE_LEVEL_CLEANER` Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To see cleaner logging, set com.sleepycat.je.cleaner.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
`static java.lang.String`	`TRACE_LEVEL_EVICTOR` Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To see evictor logging, set com.sleepycat.je.evictor.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
`static java.lang.String`	`TRACE_LEVEL_LOCK_MANAGER` Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To see locking logging, set com.sleepycat.je.txn.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
`static java.lang.String`	`TRACE_LEVEL_RECOVERY` Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To see recovery logging, set com.sleepycat.je.recovery.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
`static java.lang.String`	`TREE_BIN_DELTA` If more than this percentage of entries are changed on a BIN, log a a full version instead of a delta.
`static java.lang.String`	`TREE_COMPACT_MAX_KEY_LENGTH` Specifies the maximum unprefixed key length for use in the compact in-memory key representation.
`static java.lang.String`	`TREE_MAX_DELTA` Deprecated. as of JE 6.0. The `TREE_BIN_DELTA` param alone now determines whether a delta is logged.
`static java.lang.String`	`TREE_MAX_EMBEDDED_LN` The maximum size (in bytes) of a record's data portion that will cause the record to be embedded in its parent LN.
`static java.lang.String`	`TREE_MIN_MEMORY` The minimum bytes allocated out of the memory cache to hold Btree data including internal nodes and record keys and data.
`static java.lang.String`	`TXN_DEADLOCK_STACK_TRACE` Set this parameter to true to add stacktrace information to deadlock (lock timeout) exception messages.
`static java.lang.String`	`TXN_DUMP_LOCKS` Dump the lock table when a lock timeout is encountered, for debugging assistance.
`static java.lang.String`	`TXN_DURABILITY` Configures the default durability associated with transactions.
`static java.lang.String`	`TXN_SERIALIZABLE_ISOLATION` Configures all transactions for this environment to have Serializable (Degree 3) isolation.
`static java.lang.String`	`TXN_TIMEOUT` Configures the transaction timeout.
`static java.lang.String`	`VERIFY_BTREE` Whether the background verifier should perform Btree verification, as if the `DbVerify` utility were run.
`static java.lang.String`	`VERIFY_BTREE_BATCH_DELAY` The delay between batches during `Btree verification`.
`static java.lang.String`	`VERIFY_BTREE_BATCH_SIZE` The number of records verified per batch during `Btree verification`.
`static java.lang.String`	`VERIFY_DATA_RECORDS` Whether to verify data records (leaf nodes, or LNs) during Btree verification.
`static java.lang.String`	`VERIFY_LOG` Whether the background verifier should verify checksums in the log, as if the `DbVerifyLog` utility were run.
`static java.lang.String`	`VERIFY_LOG_READ_DELAY` The delay between reads during `log verification`.
`static java.lang.String`	`VERIFY_SCHEDULE` A crontab-format string indicating when to start the background verifier.
`static java.lang.String`	`VERIFY_SECONDARIES` Whether to verify secondary index references during Btree verification.

Constructor Summary

Constructors
Constructor and Description
`EnvironmentConfig()` Creates an EnvironmentConfig initialized with the system default settings.
`EnvironmentConfig(java.util.Properties properties)` Creates an EnvironmentConfig which includes the properties specified in the properties parameter.

Method Summary

All Methods Instance Methods Concrete Methods Deprecated Methods
Modifier and Type	Method and Description
`EnvironmentConfig`	`clone()` Returns a copy of this configuration object.
`boolean`	`getAllowCreate()` Returns a flag that specifies if we may create this environment.
`java.lang.ClassLoader`	`getClassLoader()` Returns the ClassLoader for loading user-supplied classes by name, or null if no specified ClassLoader is configured.
`CustomStats`	`getCustomStats()` Gets the custom statstics object.
`boolean`	`getLocking()` Returns true if the database environment is configured for locking.
`long`	`getLockTimeout()` Deprecated. as of 4.0, replaced by `getLockTimeout(TimeUnit)`.
`long`	`getLockTimeout(java.util.concurrent.TimeUnit unit)` Returns the lock timeout setting.
`java.util.logging.Handler`	`getLoggingHandler()` Returns the custom java.util.logging.Handler specified by the application.
`java.lang.String`	`getNodeName()` Returns the user defined nodeName for the Environment.
`boolean`	`getReadOnly()` Returns true if the database environment is configured to be read only.
`ProgressListener<RecoveryProgress>`	`getRecoveryProgressListener()` Return the ProgressListener to be used at this environment startup.
`boolean`	`getSharedCache()` A convenience method for getting the `SHARED_CACHE` parameter.
`boolean`	`getTransactional()` Returns true if the database environment is configured for transactions.
`boolean`	`getTxnSerializableIsolation()` A convenience method for getting `TXN_SERIALIZABLE_ISOLATION`.
`long`	`getTxnTimeout()` Deprecated. as of 4.0, replaced by `getTxnTimeout(TimeUnit)`.
`long`	`getTxnTimeout(java.util.concurrent.TimeUnit unit)` A convenience method for getting `TXN_TIMEOUT`.
`EnvironmentConfig`	`setAllowCreate(boolean allowCreate)` If true, creates the database environment if it doesn't already exist.
`EnvironmentConfig`	`setClassLoader(java.lang.ClassLoader classLoader)` Configure the environment to use a specified ClassLoader for loading user-supplied classes by name.
`EnvironmentConfig`	`setConfigParam(java.lang.String paramName, java.lang.String value)` Set this configuration parameter.
`EnvironmentConfig`	`setCustomStats(CustomStats customStats)` Sets the custom statistics object.
`EnvironmentConfig`	`setLocking(boolean locking)` Convenience method for setting `ENV_IS_LOCKING`.
`EnvironmentConfig`	`setLockTimeout(long timeout)` Deprecated. as of 4.0, replaced by `setLockTimeout(long, TimeUnit)`.
`EnvironmentConfig`	`setLockTimeout(long timeout, java.util.concurrent.TimeUnit unit)` Convenience method for setting `LOCK_TIMEOUT`.
`EnvironmentConfig`	`setLoggingHandler(java.util.logging.Handler handler)` Set a java.util.logging.Handler which will be used by all java.util.logging.Loggers instantiated by this Environment.
`EnvironmentConfig`	`setNodeName(java.lang.String nodeName)` Sets the user defined nodeName for the Environment.
`EnvironmentConfig`	`setReadOnly(boolean readOnly)` Convenience method for setting `ENV_READ_ONLY`.
`EnvironmentConfig`	`setRecoveryProgressListener(ProgressListener<RecoveryProgress> progressListener)` Configure the environment to make periodic calls to a ProgressListener to provide feedback on environment startup (recovery).
`EnvironmentConfig`	`setSharedCache(boolean sharedCache)` A convenience method for setting the `SHARED_CACHE` parameter.
`EnvironmentConfig`	`setTransactional(boolean transactional)` Convenience method for setting `ENV_IS_TRANSACTIONAL`.
`EnvironmentConfig`	`setTxnSerializableIsolation(boolean txnSerializableIsolation)` A convenience method for setting `TXN_SERIALIZABLE_ISOLATION`.
`EnvironmentConfig`	`setTxnTimeout(long timeout)` Deprecated. as of 4.0, replaced by `setTxnTimeout(long, TimeUnit)`.
`EnvironmentConfig`	`setTxnTimeout(long timeout, java.util.concurrent.TimeUnit unit)` A convenience method for setting `TXN_TIMEOUT`.
`java.lang.String`	`toString()` Display configuration values.

Methods inherited from class com.sleepycat.je.EnvironmentMutableConfig
getCacheMode, getCachePercent, getCacheSize, getConfigParam, getDurability, getExceptionListener, getMaxDisk, getOffHeapCacheSize, getTxnNoSync, getTxnWriteNoSync, setCacheMode, setCachePercent, setCacheSize, setDurability, setExceptionListener, setMaxDisk, setOffHeapCacheSize, setTxnNoSync, setTxnWriteNoSync

Methods inherited from class java.lang.Object
equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

- Field Detail
  - MAX_MEMORY
```
public static final java.lang.String MAX_MEMORY
```
    Configures the JE main cache size in bytes.
    Either MAX_MEMORY or MAX_MEMORY_PERCENT may be used to configure the cache size. When MAX_MEMORY is zero (its default value), MAX_MEMORY_PERCENT determines the cache size. See MAX_MEMORY_PERCENT for more information.
    
    When using MAX_MEMORY, take care to ensure that the overhead of the JVM does not leave less free space in the heap than intended. Some JVMs have more overhead than others, and some JVMs allocate their overhead within the specified heap size (the -Xmx value). To be sure that enough free space is available, use MAX_MEMORY_PERCENT rather than MAX_MEMORY.
    
    When using the Oracle NoSQL DB product
    
    Name Type Mutable Default Minimum Maximum
    
    "je.maxMemory" Long Yes 0 -none- -none-
    
    See Also:
    
    EnvironmentMutableConfig.setCacheSize(long), MAX_MEMORY_PERCENT, Cache Statistics: Sizing, Constant Field Values
  - MAX_MEMORY_PERCENT
```
public static final java.lang.String MAX_MEMORY_PERCENT
```
    Configures the JE main cache size as a percentage of the JVM maximum memory.
    The system will evict database objects when it comes within a prescribed margin of the limit.
    
    By default, JE sets the cache size to:
```
         (MAX_MEMORY_PERCENT *  JVM maximum memory) / 100
 
```
    where JVM maximum memory is specified by the JVM -Xmx flag. Note that the actual heap size may be somewhat less, depending on JVM overheads. The value used in the calculation above is the actual heap size as returned by Runtime.maxMemory().
    
    The above calculation applies when MAX_MEMORY is zero, which is its default value. Setting MAX_MEMORY to a non-zero value overrides the percentage based calculation and sets the cache size explicitly.
    
    The following details apply to setting the cache size to a percentage of the JVM heap size byte size (this parameter) as well as to a byte size (MAX_MEMORY
    
    If SHARED_CACHE is set to true, MAX_MEMORY and MAX_MEMORY_PERCENT specify the total size of the shared cache, and changing these parameters will change the size of the shared cache. New environments that join the cache may alter the cache size if their configuration uses a different cache size parameter.
    
    The size of the cache is often directly proportional to operation performance. See Cache Statistics for information on understanding and monitoring the cache. It is strongly recommended that the cache is large enough to hold all INs. See DbCacheSize for information on sizing the cache.
    
    To take full advantage of JE cache memory, it is strongly recommended that compressed oops (-XX:+UseCompressedOops) is specified when a 64-bit JVM is used and the maximum heap size is less than 32 GB. As described in the referenced documentation, compressed oops is sometimes the default JVM mode even when it is not explicitly specified in the Java command. However, if compressed oops is desired then it must be explicitly specified in the Java command when running DbCacheSize or a JE application. If it is not explicitly specified then JE will not aware of it, even if it is the JVM default setting, and will not take it into account when calculating cache memory sizes.
    
    Note that log write buffers may be flushed to disk if the cache size is changed after the environment has been opened.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.maxMemoryPercent" Integer Yes 60 1 90
    See Also:
    
    EnvironmentMutableConfig.setCachePercent(int), MAX_MEMORY, Cache Statistics: Sizing, Constant Field Values
  - MAX_OFF_HEAP_MEMORY
```
public static final java.lang.String MAX_OFF_HEAP_MEMORY
```
    Configures the number of bytes to be used as a secondary, off-heap cache. The off-heap cache is used to hold record data and Btree nodes when these are evicted from the "main cache" because it overflows. Eviction occurs according to an LRU algorithm and takes into account the user- specified CacheMode. When the off-heap cache overflows, eviction occurs there also according to the same algorithm.
    The main cache is in the Java heap and consists primarily of the Java objects making up the in-memory Btree data structure. Btree objects are not serialized the main cache, so no object materialization is needed to access the Btree there. Access to records in the main cache is therefore very fast, but the main cache has drawbacks as well: 1) The larger the main cache, the more likely it is to have Java GC performance problems. 2) When the Java heap exceeds 32GB, the "compressed OOPs" setting no longer applies and less data will fit in the same amount of memory. For these reasons, JE applications often configure a heap of 32GB or less, and a main cache that is significantly less than 32GB, leaving any additional machine memory for use by the file system cache.
    The use of the file system cache has performance benefits, but also has its own drawbacks: 1) There is a significant redundancy between the main cache and the file system cache because all data and Btree information that is logged (written) by JE appears in the file system and may also appear in the main cache. 2) It is not possible for dirty Btree information to be placed in the file system cache without logging it, this logging may be otherwise unnecessary, and the logging creates additional work for the JE cleaner; in other words, the size of the main cache alone determines the maximum size of the in-memory "dirty set".
    The off-heap cache is stored outside the Java heap using a native platform memory allocator. The current implementation relies on internals that are specific to the Oracle and IBM JDKs; however, a memory allocator interface that can be implemented for other situations is being considered for a future release. Records and Btree objects are serialized when they are placed in the off-heap cache, and they must be materialized when they are moved back to the main cache in order to access them. This serialization and materialization adds some CPU overhead and thread contention, as compared to accessing data directly in the main cache. The off-heap cache can contain dirty Btree information, so it can be used to increase the maximum size of the in-memory "dirty set".
    NOTE: If an off-heap cache is configured but cannot be used because that native allocator is not available in the JDK that is used, an IllegalStateException will be thrown by the Environment or ReplicatedEnvironment constructor. In the current release, this means that the sun.misc.Unsafe class must contain the allocateMemory method and related methods, as defined in the Oracle JDK.
    When configuring an off-heap cache you can think of the performance trade-offs in two ways. First, if the off-heap cache is considered to be a replacement for the file system cache, the serialization and materialization overhead is not increased. In this case, the use of the off-heap cache is clearly beneficial, and using the off-heap cache "instead of" the file system cache is normally recommended. Second, the off-heap cache can be used along with a main cache that is reduced in size in order to compensate for Java GC problems. In this case, the trade-off is between the additional serialization, materialization and contention overheads of the off-heap cache, as compared to the Java GC overhead.
    When dividing up available memory for the JVM heap, the off-heap cache, and for other uses, please be aware that the file system cache and the off-heap cache are different in one important respect. The file system cache automatically shrinks when memory is needed by the OS or other processes, while the off-heap cache does not. Therefore, it is best to be conservative about leaving memory free for other uses, and it is not a good idea to size the off-heap cache such that all machine memory will be allocated. If off-heap allocations or other allocations fail because there is no available memory, the process is likely to die without any exception being thrown. In one test on Linux, for example, the process was killed abruptly by the OS and the only indication of the problem was the following shown by dmesg.
```
 Out of memory: Kill process 28768 (java) score 974 or sacrifice child
 Killed process 28768 (java)
    total-vm:278255336kB, anon-rss:257274420kB, file-rss:0kB
 
```
    WARNING: Although this configuration property is mutable, it cannot be changed from zero to non-zero, or non-zero to zero. In other words, the size of the off-heap cache can be changed after initially configuring a non-zero size, but the off-heap cache cannot be turned on and off dynamically. An attempt to do so will cause an IllegalArgumentException to be thrown by the Environment or ReplicatedEnvironment constructor.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.maxOffHeapMemory" Long Yes 0 0 -none-
    See Also:
    
    EnvironmentMutableConfig.setOffHeapCacheSize(long), Cache Statistics: Sizing, Constant Field Values
  - SHARED_CACHE
```
public static final java.lang.String SHARED_CACHE
```
    If true, the shared cache is used by this environment.
    By default this parameter is false and this environment uses a private cache. If this parameter is set to true, this environment will use a cache that is shared with all other open environments in this process that also set this parameter to true. There is a single shared cache per process.
    
    By using the shared cache, multiple open environments will make better use of memory because the cache LRU algorithm is applied across all information in all environments sharing the cache. For example, if one environment is open but not recently used, then it will only use a small portion of the cache, leaving the rest of the cache for environments that have been recently used.
    
    Name Type Mutable Default
    
    "je.sharedCache" Boolean No false
    
    See Also:
    
    setSharedCache(boolean), Cache Statistics: Sizing, Constant Field Values
  - MAX_DISK
```
public static final java.lang.String MAX_DISK
```
    An upper limit on the number of bytes used for data storage. Works with FREE_DISK to define the storage limit. If the limit is exceeded, write operations will be prohibited.
    If set to zero (the default), no usage limit is enforced, meaning that all space on the storage volume, minus FREE_DISK, may be used. If MAX_DISK is non-zero, FREE_DISK is subtracted from MAX_DISK to determine the usage threshold for prohibiting write operations. If multiple JE environments share the same storage volume, setting MAX_DISK to a non-zero value is strongly recommended.
    Note: An exception to the rule above is when MAX_DISK is less than or equal to 10GB and FREE_DISK is not explicitly specified. See FREE_DISK more information.
    Both the FREE_DISK and MAX_DISK thresholds (if configured) are checked during a write operation. If either threshold is crossed, the behavior of the JE environment is as follows:
    - Application write operations will throw DiskLimitException. DiskLimitException extends OperationFailureException and will invalidate the transaction, but will not invalidate the environment. Read operations may continue even when write operations are prohibited.
    - When using NoSQL DB, the above item applies to client CRUD operations as well as operations performed on internal metadata. When a disk limit is violated, NoSQL DB will throw exceptions for client write operations and for operations that update internal metadata. Related exceptions may be logged for other internal write operations. Such exceptions will be derived from the JE DiskLimitException.
    - Environment.checkpoint(com.sleepycat.je.CheckpointConfig), Environment.sync() and Database.sync() will throw DiskLimitException.
    - Environment.close() may throw DiskLimitException when a final checkpoint is performed. However, the environment will be properly closed in other respects.
    - The JE evictor will not log dirty nodes when the cache overflows and therefore dirty nodes cannot be evicted from cache. So although read operations are allowed, cache thrashing may occur if all INs do not fit in cache as recommended.
    - In an HA environment a disk limit may be violated on a replica node but not the master node. In this case, a DiskLimitException will not be thrown by a write operation on the master node. Instead, InsufficientAcksException or InsufficientReplicasException will be thrown if the ack requirements are not met.
    JE uses a log structured storage system where data files often become gradually obsolete over time (see CLEANER_MIN_UTILIZATION). The JE cleaner is responsible for reclaiming obsolete space by cleaning and deleting data files. In a standalone (non-HA) environment, data files are normally deleted quickly after being cleaned, but may be reserved and protected temporarily by a DbBackup or DiskOrderedCursor. These reserved files will be deleted as soon as they are no longer protected.
    In an HA environment, JE will retain as many reserved files as possible to support replication to nodes that are out of contact. All cleaned files are reserved (not deleted) until approaching a disk limit, at which time they are deleted, as long as they are not protected. Reserved files are protected when they are needed for replication to active nodes or for feeding an active network restore.
    For more information on reserved and protected data files, see EnvironmentStats.getActiveLogSize(), EnvironmentStats.getReservedLogSize(), EnvironmentStats.getProtectedLogSize(), EnvironmentStats.getProtectedLogSizeMap(), EnvironmentStats.getAvailableLogSize() and EnvironmentStats.getTotalLogSize().
    When multiple JE environments share the same storage volume, the FREE_DISK amount will be maintained for each environment. The following scenario illustrates use of a single shared volume with capacity 300GB:
    - JE-1 and JE-2 each have MAX_DISK=100GB and FREE_DISK=5GB,
    - 100GB is used for fixed miscellaneous storage.
    Each JE environment will use no more than 95GB each, so at least 10GB will remain free overall. In other words, if both JE environments reach their threshold and write operations are prohibited, each JE environment will have 5GB of free space for recovery (10GB total).
    On the other hand, when an external service is also consuming disk space and its usage of disk space is variable over time, the situation is more complex and JE cannot always guarantee that FREE_DISK is honored. The following scenario includes multiple JE environments as well an external service, all sharing a 300GB volume.
    - JE-1 and JE-2 each have MAX_DISK=100GB and FREE_DISK=5GB,
    - an external service is expected to use up to 50GB, and
    - 50GB is used for fixed miscellaneous storage.
    Assuming that the external service stays within its 50GB limit then, as the previous example, each JE environment will normally use no more than 95GB each, and at least 10GB will remain free overall. However, if the external service exceeds its threshold, JE will make a best effort to prohibit write operations in order to honor the FREE_DISK limit, but this is not always possible, as illustrated by the following sequence of events:
    - If the external service uses all its allocated space, 50GB, and JE environments are each using 75GB, then there will be 50GB free overall (25GB for each JE environment). Write operations are allowed in both JE environments.
    - If the external service then exceeds its limit by 25GB and uses 75GB, there will only 25GB free overall. But each JE environment is still under its 90GB limit and there is still more than 5GB free overall, so write operations are still allowed.
    - If each JE environment uses an additional 10GB of space, there will only be 5GB free overall. Each JE environment is using only 85GB, which is under its 95GB limit. But the 5GB FREE_DISK limit for the volume overall has been reached and therefore JE write operations will be prohibited.
    Leaving only 5GB of free space in the prior scenario is not ideal, but it is at least enough for one JE environment at a time to be recovered. The reality is that when an external entity exceeds its expected disk usage, JE cannot always compensate. For example, if the external service continues to use more space in the scenario above, the volume will eventually be filled completely.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.maxDisk" Long Yes 0 0 -none-
    Since:
    
    7.5
    
    See Also:
    
    FREE_DISK, EnvironmentMutableConfig.setMaxDisk(long), EnvironmentMutableConfig.getMaxDisk(), Constant Field Values
  - FREE_DISK
```
public static final java.lang.String FREE_DISK
```
    A lower limit on the number of bytes of free space to maintain on a volume and per JE Environment. Works with MAX_DISK to define the storage limit. If the limit is exceeded, write operations will be prohibited.
    The default FREE_DISK value is 5GB. This value is designed to be large enough to allow manual recovery after exceeding a disk threshold.
    If FREE_DISK is set to zero, no free space limit is enforced. This is not recommended, since manual recovery may be very difficult or impossible when the volume is completely full.
    If non-zero, this parameter is used in two ways.
    - FREE_DISK determines the minimum of free space left on the storage volume. If less than this amount is free, write operations are prohibited.
    - If MAX_DISK is configured, FREE_DISK is subtracted from MAX_DISK to determine the usage threshold for prohibiting write operations. See MAX_DISK for more information.
      Note that this subtraction could make testing inconvenient when a small value is specified for MAX_DISK and FREE_DISK is not also specified. For example, if MAX_DISK is 1GB and FREE_DISK is 5G (its default value), then no writing would be allowed (MAX_DISK minus FREE_DISK is negative 4G). To address this, the subtraction is performed only if one of two conditions is met:
      
      FREE_DISK is explicitly specified, or
      
      MAX_DISK is greater than 10GB.
    Name Type Mutable Default Minimum Maximum
    
    "je.freeDisk" Long Yes 5,368,709,120 (5GB) -none- -none-
    Since:
    
    7.5
    
    See Also:
    
    MAX_DISK, Constant Field Values
  - ENV_RECOVERY_FORCE_CHECKPOINT
```
public static final java.lang.String ENV_RECOVERY_FORCE_CHECKPOINT
```
    If true, a checkpoint is forced following recovery, even if the log ends with a checkpoint.
    
    Name Type Mutable Default
    
    "je.env.recoveryForceCheckpoint" Boolean No false
    
    See Also:
    
    Constant Field Values
  - ENV_RECOVERY_FORCE_NEW_FILE
```
public static final java.lang.String ENV_RECOVERY_FORCE_NEW_FILE
```
    Used after performing a restore from backup to force creation of a new log file prior to recovery.
    As of JE 6.3, the use of this parameter is unnecessary except in special cases. See the "Restoring from a backup" section in the DbBackup javadoc for more information.
    
    Name Type Mutable Default
    
    "je.env.recoveryForceNewFile" Boolean No false
    
    See Also:
    
    Restoring from a backup, Constant Field Values
  - HALT_ON_COMMIT_AFTER_CHECKSUMEXCEPTION
```
public static final java.lang.String HALT_ON_COMMIT_AFTER_CHECKSUMEXCEPTION
```
    By default, if a checksum exception is found at the end of the log during Environment startup, JE will assume the checksum is due to previously interrupted I/O and will quietly truncate the log and restart. If this property is set to true, when a ChecksumException occurs in the last log file during recovery, instead of truncating the log file, and automatically restarting, attempt to continue reading past the corrupted record with the checksum error to see if there are commit records following the corruption. If there are, throw an EnvironmentFailureException to indicate the presence of committed transactions. The user may then need to run DbTruncateLog to truncate the log for further recovery after doing manual analysis of the log. Setting this property is suitable when the application wants to guard against unusual cases.
    
    Name Type Mutable Default
    
    "je.haltOnCommitAfterChecksumException" Boolean No false
    
    See Also:
    
    Constant Field Values
  - ENV_RUN_IN_COMPRESSOR
```
public static final java.lang.String ENV_RUN_IN_COMPRESSOR
```
    If true, starts up the INCompressor thread.
    
    Name Type Mutable Default
    
    "je.env.runINCompressor" Boolean Yes true
    
    See Also:
    
    Constant Field Values
  - ENV_RUN_CHECKPOINTER
```
public static final java.lang.String ENV_RUN_CHECKPOINTER
```
    If true, starts up the checkpointer thread.
    
    Name Type Mutable Default
    
    "je.env.runCheckpointer" Boolean Yes true
    
    See Also:
    
    Constant Field Values
  - ENV_RUN_CLEANER
```
public static final java.lang.String ENV_RUN_CLEANER
```
    If true, starts up the cleaner thread.
    
    Name Type Mutable Default
    
    "je.env.runCleaner" Boolean Yes true
    
    See Also:
    
    Constant Field Values
  - ENV_RUN_EVICTOR
```
public static final java.lang.String ENV_RUN_EVICTOR
```
    If true, eviction is done by a pool of evictor threads, as well as being done inline by application threads. If false, the evictor pool is not used, regardless of the values of EVICTOR_CORE_THREADS and EVICTOR_MAX_THREADS.
    
    Name Type Mutable Default
    
    "je.env.runEvictor" Boolean Yes true
    
    See Also:
    
    Constant Field Values
  - ENV_RUN_OFFHEAP_EVICTOR
```
public static final java.lang.String ENV_RUN_OFFHEAP_EVICTOR
```
    If true, off-heap eviction is done by a pool of evictor threads, as well as being done inline by application threads. If false, the evictor pool is not used, regardless of the values of OFFHEAP_CORE_THREADS and OFFHEAP_MAX_THREADS.
    
    Name Type Mutable Default
    
    "je.env.runOffHeapEvictor" Boolean Yes true
    
    See Also:
    
    Constant Field Values
  - ENV_BACKGROUND_READ_LIMIT
```
public static final java.lang.String ENV_BACKGROUND_READ_LIMIT
```
    The maximum number of read operations performed by JE background activities (e.g., cleaning) before sleeping to ensure that application threads can perform I/O. If zero (the default) then no limitation on I/O is enforced.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.backgroundReadLimit" Integer Yes 0 0 -none-
    
    See Also:
    
    ENV_BACKGROUND_SLEEP_INTERVAL, Constant Field Values
  - ENV_BACKGROUND_WRITE_LIMIT
```
public static final java.lang.String ENV_BACKGROUND_WRITE_LIMIT
```
    The maximum number of write operations performed by JE background activities (e.g., checkpointing and eviction) before sleeping to ensure that application threads can perform I/O. If zero (the default) then no limitation on I/O is enforced.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.backgroundWriteLimit" Integer Yes 0 0 -none-
    
    See Also:
    
    ENV_BACKGROUND_SLEEP_INTERVAL, Constant Field Values
  - ENV_BACKGROUND_SLEEP_INTERVAL
```
public static final java.lang.String ENV_BACKGROUND_SLEEP_INTERVAL
```
    The duration that JE background activities will sleep when the ENV_BACKGROUND_WRITE_LIMIT or ENV_BACKGROUND_READ_LIMIT is reached. If ENV_BACKGROUND_WRITE_LIMIT and ENV_BACKGROUND_READ_LIMIT are zero, this setting is not used.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.backgroundSleepInterval" Duration Yes 1 ms 1 ms 24 d
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - ENV_CHECK_LEAKS
```
public static final java.lang.String ENV_CHECK_LEAKS
```
    Debugging support: check leaked locks and txns at env close.
    
    Name Type Mutable Default
    
    "je.env.checkLeaks" Boolean No true
    
    See Also:
    
    Constant Field Values
  - ENV_FORCED_YIELD
```
public static final java.lang.String ENV_FORCED_YIELD
```
    Debugging support: call Thread.yield() at strategic points.
    
    Name Type Mutable Default
    
    "je.env.forcedYield" Boolean No false
    
    See Also:
    
    Constant Field Values
  - ENV_IS_TRANSACTIONAL
```
public static final java.lang.String ENV_IS_TRANSACTIONAL
```
    Configures the use of transactions.
    This should be set to true when transactional guarantees such as atomicity of multiple operations and durability are important.
    
    If true, create an environment that is capable of performing transactions. If true is not passed, transactions may not be used. For licensing purposes, the use of this method distinguishes the use of the Transactional product. Note that if transactions are not used, specifying true does not create additional overhead in the environment.
    
    Name Type Mutable Default
    
    "je.env.isTransactional" Boolean No false
    
    See Also:
    
    setTransactional(boolean), Constant Field Values
  - ENV_IS_LOCKING
```
public static final java.lang.String ENV_IS_LOCKING
```
    Configures the database environment for no locking.
    If true, create the environment with record locking. This property should be set to false only in special circumstances when it is safe to run without record locking.
    
    This configuration option should be used when locking guarantees such as consistency and isolation are not important. If locking mode is disabled (it is enabled by default), the cleaner is automatically disabled. The user is responsible for invoking the cleaner and ensuring that there are no concurrent operations while the cleaner is running.
    
    Name Type Mutable Default
    
    "je.env.isLocking" Boolean No true
    
    See Also:
    
    setLocking(boolean), Constant Field Values
  - ENV_READ_ONLY
```
public static final java.lang.String ENV_READ_ONLY
```
    Configures the database environment to be read-only, and any attempt to modify a database will fail.
    A read-only environment has several limitations and is recommended only in special circumstances. Note that there is no performance advantage to opening an environment read-only.
    
    The primary reason for opening an environment read-only is to open a single environment in multiple JVM processes. Only one JVM process at a time may open the environment read-write. See EnvironmentLockedException.
    
    When the environment is open read-only, the following limitations apply.
    - In the read-only environment no writes may be performed, as expected, and databases must be opened read-only using DatabaseConfig.setReadOnly(boolean).
    - The read-only environment receives a snapshot of the data that is effectively frozen at the time the environment is opened. If the application has the environment open read-write in another JVM process and modifies the environment's databases in any way, the read-only version of the data will not be updated until the read-only JVM process closes and reopens the environment (and by extension all databases in that environment).
    - If the read-only environment is opened while the environment is in use by another JVM process in read-write mode, opening the environment read-only (recovery) is likely to take longer than it does after a clean shutdown. This is due to the fact that the read-write JVM process is writing and checkpoints are occurring that are not coordinated with the read-only JVM process. The effect is similar to opening an environment after a crash.
    - In a read-only environment, the JE cache will contain information that cannot be evicted because it was reconstructed by recovery and cannot be flushed to disk. This means that the read-only environment may not be suitable for operations that use large amounts of memory, and poor performance may result if this is attempted.
    - In a read-write environment, the log cleaner will be prohibited from deleting log files for as long as the environment is open read-only in another JVM process. This may cause disk usage to rise, and for this reason it is not recommended that an environment is kept open read-only in this manner for long periods.
    For these reasons, it is recommended that a read-only environment be used only for short periods and for operations that are not performance critical or memory intensive. With few exceptions, all application functions that require access to a JE environment should be built into a single application so that they can be performed in the JVM process where the environment is open read-write.
    
    In most applications, opening an environment read-only can and should be avoided.
    
    Name Type Mutable Default
    
    "je.env.isReadOnly" Boolean No false
    See Also:
    
    setReadOnly(boolean), Constant Field Values
  - ENV_FAIR_LATCHES
```
public static final java.lang.String ENV_FAIR_LATCHES
```
    If true, use latches instead of synchronized blocks to implement the lock table and log write mutexes. Latches require that threads queue to obtain the mutex in question and therefore guarantee that there will be no mutex starvation, but do incur a performance penalty. Latches should not be necessary in most cases, so synchronized blocks are the default. An application that puts heavy load on JE with threads with different thread priorities might find it useful to use latches. In a Java 5 JVM, where java.util.concurrent.locks.ReentrantLock is used for the latch implementation, this parameter will determine whether they are 'fair' or not. This parameter is 'static' across all environments.
    
    Name Type Mutable Default
    
    "je.env.fairLatches" Boolean No false
    
    See Also:
    
    Constant Field Values
  - ENV_LATCH_TIMEOUT
```
public static final java.lang.String ENV_LATCH_TIMEOUT
```
    The timeout for detecting internal latch timeouts, so that deadlocks can be detected. Latches are held internally for very short durations. If due to unforeseen problems a deadlock occurs, a timeout will occur after the duration specified by this parameter. When a latch timeout occurs:
    - The Environment is invalidated and must be closed.
    - An EnvironmentFailureException is thrown.
    - A full thread dump is logged at level SEVERE.
    If this happens, thread dump in je.info file should be preserved so it can be used to analyze the problem.
    Most applications should not change this parameter. The default value, 5 minutes, should be much longer than a latch is ever held.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.latchTimeout" Duration No 5 min 1 ms -none-
    Since:
    
    6.2
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - ENV_TTL_CLOCK_TOLERANCE
```
public static final java.lang.String ENV_TTL_CLOCK_TOLERANCE
```
    The interval added to the system clock time for determining that a record may have expired. Used when an internal integrity error may be present, but may also be due to a record that expired and the system clock was moved back.
    For example, say a record expires and then the clock is moved back by one hour to correct a daylight savings time error. Because the LN and BIN slot for an expired record are purged separately (see Time-To_live), in this case the LN was purged but the BIN slot was not purged. When accessing the record's key via the BIN slot, it will appear that it is not expired. But then when accessing the the data, the LN will not be accessible. Normally this would be considered a fatal integrity error, but since the record will expire within the 2 hour limit, it is simply treated as an expired record.
    Most applications should not change this parameter. The default value, two hours, is enough to account for minor clock adjustments or accidentally setting the clock one hour off.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.ttlClockTolerance" Duration No 2 h 1 ms -none-
    
    Since:
    
    7.0
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - ENV_EXPIRATION_ENABLED
```
public static final java.lang.String ENV_EXPIRATION_ENABLED
```
    If true (the default), expired data is filtered from queries and purged by the cleaner. This might be set to false to recover data after an extended down time.
    WARNING: Disabling expiration is intended for special-purpose access for data recovery only. When this parameter is set to false, records that have expired may or may not have been purged, so they may or may not be accessible. In addition, it is possible for the key and data of a record to expire independently, so the key may be accessible (if the data is not requested by the read operation), while the record will appear to be deleted when the data is requested. The same thing is true of primary and secondary records, which are also purged independently. A record may be accessible by primary key but not secondary key, and vice-versa.
    
    Name Type Mutable Default
    
    "je.env.expirationEnabled" Boolean yes true
    
    See Also:
    
    Constant Field Values
  - ENV_DB_EVICTION
```
public static final java.lang.String ENV_DB_EVICTION
```
    If true, enable eviction of metadata for closed databases. There is no known benefit to setting this parameter to false.
    This param is unlikely to be needed for tuning, but is sometimes useful for debugging and testing.
    
    Name Type Mutable Default
    
    "je.env.dbEviction" Boolean No true
    
    See Also:
    
    Cache Statistics: Debugging, Constant Field Values
  - ENV_DUP_CONVERT_PRELOAD_ALL
```
public static final java.lang.String ENV_DUP_CONVERT_PRELOAD_ALL
```
    If true (the default) preload all duplicates databases at once when upgrading from JE 4.1 and earlier. If false, preload each duplicates database individually instead. Preloading all databases at once gives a performance advantage if the JE cache is roughly large enough to contain the internal nodes for all duplicates databases. Preloading each database individually gives a performance advantage if the JE cache is roughly large enough to contain the internal nodes for a single duplicates database.
    
    Name Type Mutable Default
    
    "je.env.dupConvertPreloadAll" Boolean No true
    
    See Also:
    
    Constant Field Values
  - ADLER32_CHUNK_SIZE
```
public static final java.lang.String ADLER32_CHUNK_SIZE
```
    By default, JE passes an entire log record to the Adler32 class for checksumming. This can cause problems with the GC in some cases if the records are large and there is concurrency. 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.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.adler32.chunkSize" Integer Yes 0 0 1048576 (1M)
    
    See Also:
    
    Constant Field Values
  - LOG_TOTAL_BUFFER_BYTES
```
public static final java.lang.String LOG_TOTAL_BUFFER_BYTES
```
    The total memory taken by log buffers, in bytes. If 0, use 7% of je.maxMemory. If 0 and je.sharedCache=true, use 7% divided by N where N is the number of environments sharing the global cache.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.totalBufferBytes" Long No 0 6144L -none-
    
    See Also:
    
    Constant Field Values
  - LOG_NUM_BUFFERS
```
public static final java.lang.String LOG_NUM_BUFFERS
```
    The number of JE log buffers.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.numBuffers" Integer No 3 2 -none-
    
    See Also:
    
    Constant Field Values
  - LOG_BUFFER_SIZE
```
public static final java.lang.String LOG_BUFFER_SIZE
```
    The maximum starting size of a JE log buffer. JE silently restricts this value to be no more than the configured maximum log file size (je.log.fileMax).
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.bufferSize" Integer No 1048576 (1M) 1024 (1K) -none-
    
    See Also:
    
    Constant Field Values
  - LOG_FAULT_READ_SIZE
```
public static final java.lang.String LOG_FAULT_READ_SIZE
```
    The buffer size for faulting in objects from disk, in bytes.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.faultReadSize" Integer No 2048 (2K) 32 -none-
    
    See Also:
    
    Constant Field Values
  - LOG_ITERATOR_READ_SIZE
```
public static final java.lang.String LOG_ITERATOR_READ_SIZE
```
    The read buffer size for log iterators, which are used when scanning the log during activities like log cleaning and environment open, in bytes. This may grow as the system encounters larger log entries.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.iteratorReadSize" Integer No 8192 (8K) 128 -none-
    
    See Also:
    
    Constant Field Values
  - LOG_ITERATOR_MAX_SIZE
```
public static final java.lang.String LOG_ITERATOR_MAX_SIZE
```
    The maximum read buffer size for log iterators, which are used when scanning the log during activities like log cleaning and environment open, in bytes.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.iteratorMaxSize" Integer No 16777216 (16M) 128 -none-
    
    See Also:
    
    Constant Field Values
  - LOG_FILE_MAX
```
public static final java.lang.String LOG_FILE_MAX
```
    The maximum size of each individual JE log file, in bytes.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.fileMax" Long No 10000000 (10M) 1000000 (1M) 1073741824 (1G)
    
    See Also:
    
    Constant Field Values
  - LOG_N_DATA_DIRECTORIES
```
public static final java.lang.String LOG_N_DATA_DIRECTORIES
```
    Deprecated. as of 7.3. This feature is not known to provide benefits beyond that of a simple RAID configuration, and will be removed in the next release, which is slated for mid-April, 2017.
    
    The JE environment can be spread across multiple subdirectories. Environment subdirectories may be used to spread an environment's .jdb files over multiple directories, and therefore over multiple disks or file systems. Environment subdirectories reside in the environment home directory and are named data001/ through dataNNN/, consecutively, where NNN is the value of je.log.nDataDirectories. A typical configuration would be to have each of the dataNNN/ names be symbolic links to actual directories which each reside on separate file systems or disks.
    If 0, all log files (*.jdb) will reside in the environment home directory passed to the Environment constructor. A non-zero value indicates the number of environment subdirectories to use for holding the environment log files.
    If data subdirectories are used (i.e. je.log.nDataDirectories > 0), this parameter must be set when the environment is initially created. Like the environment home directory, each and every one of the dataNNN/ subdirectories must also be present and writable. This parameter must be set to the same value for all subsequent openings of the environment or an exception will be thrown.
    If the set of existing dataNNN/ subdirectories is not equivalent to the set { 1 ... je.log.nDataDirectories } when the environment is opened, an EnvironmentFailureException will be thrown, and the Environment will fail to be opened.
    This parameter should be set using the je.properties file rather than the EnvironmentConfig. If not, JE command line utilities that open the Environment will throw an exception because they will not know of the non-zero value of this parameter.
    
    Name Type Mutable Default Minimum Maximum JVM
    
    "je.log.nDataDirectories" Integer No 0 0 256
    
    See Also:
    
    Constant Field Values
  - LOG_CHECKSUM_READ
```
public static final java.lang.String LOG_CHECKSUM_READ
```
    If true, perform a checksum check when reading entries from log.
    
    Name Type Mutable Default
    
    "je.log.checksumRead" Boolean No true
    
    See Also:
    
    Constant Field Values
  - LOG_VERIFY_CHECKSUMS
```
public static final java.lang.String LOG_VERIFY_CHECKSUMS
```
    If true, perform a checksum verification just before and after writing to the log. This is primarily used for debugging.
    
    Name Type Mutable Default
    
    "je.log.verifyChecksums" Boolean No false
    
    See Also:
    
    Constant Field Values
  - LOG_MEM_ONLY
```
public static final java.lang.String LOG_MEM_ONLY
```
    If true, operates in an in-memory test mode without flushing the log to disk. An environment directory must be specified, but it need not exist and no files are written. The system operates until it runs out of memory, at which time an OutOfMemoryError is thrown. Because the entire log is kept in memory, this mode is normally useful only for testing.
    
    Name Type Mutable Default
    
    "je.log.memOnly" Boolean No false
    
    See Also:
    
    Constant Field Values
  - LOG_FILE_CACHE_SIZE
```
public static final java.lang.String LOG_FILE_CACHE_SIZE
```
    The size of the file handle cache.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.fileCacheSize" Integer No 100 3 -none-
    
    See Also:
    
    Constant Field Values
  - LOG_DETECT_FILE_DELETE
```
public static final java.lang.String LOG_DETECT_FILE_DELETE
```
    If true, periodically detect unexpected file deletions. Normally all file deletions should be performed as a result of JE log cleaning. If an external file deletion is detected, JE assumes this was accidental. This will cause the environment to be invalidated and all methods will throw EnvironmentFailureException.
    
    Name Type Mutable Default
    
    "je.log.detectFileDelete" Boolean No true
    
    Since:
    
    7.2
    
    See Also:
    
    Constant Field Values
  - LOG_DETECT_FILE_DELETE_INTERVAL
```
public static final java.lang.String LOG_DETECT_FILE_DELETE_INTERVAL
```
    The interval used to check for unexpected file deletions.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.detectFileDeleteInterval" Duration No 1000 ms 1 ms none
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - LOG_FSYNC_TIMEOUT
```
public static final java.lang.String LOG_FSYNC_TIMEOUT
```
    The timeout limit for group file sync, in microseconds.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.fsyncTimeout" Duration No 500 ms 10 ms 24 d
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - LOG_FSYNC_TIME_LIMIT
```
public static final java.lang.String LOG_FSYNC_TIME_LIMIT
```
    If the time taken by an fsync exceeds this limit, a WARNING level message is logged. If this parameter set to zero, a message will not be logged. By default, this parameter is 5 seconds.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.fsyncTimeLimit" Duration No 5 s zero 30 s
    
    Since:
    
    7.0
    
    See Also:
    
    EnvironmentStats.getFSyncMaxTime(), Time Duration Properties, Constant Field Values
  - LOG_GROUP_COMMIT_INTERVAL
```
public static final java.lang.String LOG_GROUP_COMMIT_INTERVAL
```
    The time interval in nanoseconds during which transactions may be grouped to amortize the cost of write and/or fsync when a transaction commits with SyncPolicy#SYNC or SyncPolicy#WRITE_NO_SYNC on the local machine.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.groupCommitInterval" Duration No 0 0 none
    
    Since:
    
    5.0.76
    
    See Also:
    
    Time Duration Properties, LOG_GROUP_COMMIT_THRESHOLD, Constant Field Values
  - LOG_GROUP_COMMIT_THRESHOLD
```
public static final java.lang.String LOG_GROUP_COMMIT_THRESHOLD
```
    The threshold value impacts the number of transactions that may be grouped to amortize the cost of write and/or fsync when a transaction commits with SyncPolicy#SYNC or SyncPolicy#WRITE_NO_SYNC on the local machine.
    Specifying larger values can result in more transactions being grouped together decreasing average commit times.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.groupCommitThreshold" Integer No 0 0 -none-
    
    Since:
    
    5.0.76
    
    See Also:
    
    LOG_GROUP_COMMIT_INTERVAL, Constant Field Values
  - LOG_FLUSH_SYNC_INTERVAL
```
public static final java.lang.String LOG_FLUSH_SYNC_INTERVAL
```
    The maximum time interval between committing a transaction with NO_SYNC or WRITE_NO_SYNC durability, and making the transaction durable with respect to the storage device. To provide this guarantee, a JE background thread is used to flush any data buffered by JE to the file system, and also perform an fsync to force any data buffered by the file system to the storage device. If this parameter is set to zero, this JE background task is disabled and no such guarantee is provided.
    Separately, the LOG_FLUSH_NO_SYNC_INTERVAL flushing provides a guarantee that data is periodically flushed to the file system. To guard against data loss due to an OS crash (and to improve performance) we recommend that the file system is configured to periodically flush dirty pages to the storage device. This parameter, LOG_FLUSH_SYNC_INTERVAL, provides a fallback for flushing to the storage device, in case the file system is not adequately configured.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.flushSyncInterval" Duration Yes 20 s 0 -none-
    
    Since:
    
    7.2
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - LOG_FLUSH_NO_SYNC_INTERVAL
```
public static final java.lang.String LOG_FLUSH_NO_SYNC_INTERVAL
```
    The maximum time interval between committing a transaction with NO_SYNC durability, and making the transaction durable with respect to the file system. To provide this guarantee, a JE background thread is used to flush any data buffered by JE to the file system. If this parameter is set to zero, this JE background task is disabled and no such guarantee is provided.
    Frequent periodic flushing to the file system provides improved durability for NO_SYNC transactions. Without this flushing, if application write operations stop, then some number of NO_SYNC transactions would be left in JE memory buffers and would be lost in the event of a crash. For HA applications, this flushing reduces the possibility of RollbackProhibitedException. Note that periodic flushing reduces the time window where a crash can cause transaction loss and RollbackProhibitedException, but the window cannot be closed completely when using NO_SYNC durability.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.flushNoSyncInterval" Duration Yes 5 s 0 -none-
    
    Since:
    
    7.2
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - LOG_USE_ODSYNC
```
public static final java.lang.String LOG_USE_ODSYNC
```
    If true (default is false) O_DSYNC is used to open JE log files.
    
    Name Type Mutable Default
    
    "je.log.useODSYNC" Boolean No false
    
    See Also:
    
    Constant Field Values
  - LOG_USE_NIO
```
public static final java.lang.String LOG_USE_NIO
```
    Deprecated. NIO is no longer used by JE and this parameter has no effect.
    
    See Also:
    
    Constant Field Values
  - LOG_USE_WRITE_QUEUE
```
public static final java.lang.String LOG_USE_WRITE_QUEUE
```
    If true (default is true) the Write Queue is used for file I/O operations which are blocked by concurrent I/O operations.
    
    Name Type Mutable Default
    
    "je.log.useWriteQueue" Boolean No true
    
    See Also:
    
    Constant Field Values
  - LOG_WRITE_QUEUE_SIZE
```
public static final java.lang.String LOG_WRITE_QUEUE_SIZE
```
    The size of the Write Queue.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.log.writeQueueSize" Integer No 1MB 4KB 32MB-
    
    See Also:
    
    Constant Field Values
  - LOG_DIRECT_NIO
```
public static final java.lang.String LOG_DIRECT_NIO
```
    Deprecated. NIO is no longer used by JE and this parameter has no effect.
    
    See Also:
    
    Constant Field Values
  - LOG_CHUNKED_NIO
```
public static final java.lang.String LOG_CHUNKED_NIO
```
    Deprecated. NIO is no longer used by JE and this parameter has no effect.
    
    See Also:
    
    Constant Field Values
  - ENV_RUN_VERIFIER
```
public static final java.lang.String ENV_RUN_VERIFIER
```
    Whether to run the background verifier.
    If true (the default), the verifier runs according to the schedule given by VERIFY_SCHEDULE. Each time the verifier runs, it performs checksum verification if the VERIFY_LOG setting is true and performs Btree verification if the VERIFY_BTREE setting is true.
    When corruption is detected, the Environment will be invalidated and an EnvironmentFailureException will be thrown. Applications catching this exception can call the new EnvironmentFailureException.isCorrupted() method to determine whether corruption was detected.
    If isCorrupted returns true, a full restore (an HA NetworkRestore or restore from backup) should be performed to avoid further problems. The advantage of performing verification frequently is that a problem may be detected sooner than it would be otherwise. For HA applications, this means that the network restore can be done while the other nodes in the group are up, minimizing exposure to additional failures.
    When index corruption is detected, the environment is not invalidated. Instead, the corrupt index (secondary database) is marked as corrupt in memory and a warning message is logged. All subsequent access to the index will throw SecondaryIntegrityException. To correct the problem, the application may perform a full restore or rebuild the corrupt index.
    
    Name Type Mutable Default
    
    "je.env.runVerifier" Boolean Yes true
    
    Since:
    
    7.3
    
    See Also:
    
    Constant Field Values
  - VERIFY_SCHEDULE
```
public static final java.lang.String VERIFY_SCHEDULE
```
    A crontab-format string indicating when to start the background verifier.
    See https://en.wikipedia.org/wiki/Cron#Configuration_file Note that times and dates are specified in local time, not UTC time.
    The data verifier will run at most once per scheduled interval. If the complete verification (log verification followed by Btree verification) takes longer than the scheduled interval, then the next verification will start at the next increment of the interval. For example, if the default schedule is used (one per day at midnight), and verification takes 25 hours, then verification will occur once every two days (48 hours), starting at midnight.
    
    Name Type Mutable Default
    
    "je.env.verifySchedule" String Yes "0 0 * * * (run once a day at midnight, local time)"
    
    Since:
    
    7.3
    
    See Also:
    
    Constant Field Values
  - VERIFY_LOG
```
public static final java.lang.String VERIFY_LOG
```
    Whether the background verifier should verify checksums in the log, as if the DbVerifyLog utility were run.
    If true, the entire log is read sequentially and verified. The size of the read buffer is determined by LOG_ITERATOR_READ_SIZE.
    
    Name Type Mutable Default
    
    "je.env.verifyLog" Boolean Yes true
    
    Since:
    
    7.3
    
    See Also:
    
    Constant Field Values
  - VERIFY_LOG_READ_DELAY
```
public static final java.lang.String VERIFY_LOG_READ_DELAY
```
    The delay between reads during log verification. A delay between reads is needed to allow other JE components, such as HA, to make timely progress.
    A 100ms delay, the default value, with the read buffer size 131072, i.e. 128K, for a 1GB file, the total delay time is about 13 minutes.
    This parameter applies only to the background verifier. It does not apply to use of DbVerifyLog.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.verifyLogReadDelay" Duration Yes 100 ms 0 ms 10 s
    
    Since:
    
    7.5
    
    See Also:
    
    Constant Field Values
  - VERIFY_BTREE
```
public static final java.lang.String VERIFY_BTREE
```
    Whether the background verifier should perform Btree verification, as if the DbVerify utility were run.
    If true, the Btree of all databases, external and internal, is verified. The in-memory cache is used for verification and internal data structures are checked. References to data records (log sequence numbers, or LSNs) are checked to ensure they do not refer to deleted files -- this is the most common type of corruption. Additional checks are performed, depending on the settings for VERIFY_SECONDARIES and VERIFY_DATA_RECORDS.
    
    Name Type Mutable Default
    
    "je.env.verifyBtree" Boolean Yes true
    
    Since:
    
    7.5
    
    See Also:
    
    Constant Field Values
  - VERIFY_SECONDARIES
```
public static final java.lang.String VERIFY_SECONDARIES
```
    Whether to verify secondary index references during Btree verification.
    An index record contains a reference to a primary key, and the verification involves checking that a record for the primary key exists.
    Note that secondary index references are verified only for each SecondaryDatabase (and SecondaryIndex) that is currently open. The relationship between a secondary and primary database is not stored persistently, so JE is not aware of the relationship unless the secondary database has been opened by the application.
    
    Name Type Mutable Default
    
    "je.env.verifySecondaries" Boolean Yes true
    
    Since:
    
    7.5
    
    See Also:
    
    Constant Field Values
  - VERIFY_DATA_RECORDS
```
public static final java.lang.String VERIFY_DATA_RECORDS
```
    Whether to verify data records (leaf nodes, or LNs) during Btree verification.
    Regardless of this parameter's value, the Btree reference to the data record (the log sequence number, or LSN) is checked to ensure that it doesn't refer to a file that has been deleted by the JE cleaner -- this sort of "dangling reference" is the most common type of corruption. If this parameter value is true, the LN is additionally fetched from disk (if not in cache) to verify that the LSN refers to a valid log entry. Because LNs are often not cached, this can cause expensive random IO, and the default value for this parameter is false for this reason. Some applications may choose to set this parameter to true, for example, when using a storage device with fast random IO (an SSD).
    Note that Btree internal nodes (INs) are always fetched from disk during verification, if they are not in cache, and this can result in random IO. Verification was implemented with the assumption that most INs will be in cache.
    
    Name Type Mutable Default
    
    "je.env.verifyDataRecords" Boolean Yes false
    
    Since:
    
    7.5
    
    See Also:
    
    Constant Field Values
  - VERIFY_BTREE_BATCH_SIZE
```
public static final java.lang.String VERIFY_BTREE_BATCH_SIZE
```
    The number of records verified per batch during Btree verification. In order to give database remove/truncate the opportunity to execute, records are verified in batches and there is a delay between batches.
    This parameter applies only to the background verifier. It does not apply to use of DbVerify.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.verifyBtreeBatchSize" Integer Yes 1000 1 10000
    
    See Also:
    
    Constant Field Values
  - VERIFY_BTREE_BATCH_DELAY
```
public static final java.lang.String VERIFY_BTREE_BATCH_DELAY
```
    The delay between batches during Btree verification. In order to give database remove/truncate the opportunity to execute, records are verified in batches and there is a delay between batches.
    A 10ms delay, the default value, should be enough to allow other threads to run. A large value, for example 1s, would result in a total delay of 28 hours when verifying 100m records or 100k batches.
    This parameter applies only to the background verifier. It does not apply to use of DbVerify.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.verifyBtreeBatchDelay" Duration Yes 10 ms 0 ms 10 s
    
    See Also:
    
    Constant Field Values
  - NODE_MAX_ENTRIES
```
public static final java.lang.String NODE_MAX_ENTRIES
```
    The maximum number of entries in an internal btree node. This can be set per-database using the DatabaseConfig object.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.nodeMaxEntries" Integer No 128 4 32767 (32K)
    
    See Also:
    
    Constant Field Values
  - NODE_DUP_TREE_MAX_ENTRIES
```
public static final java.lang.String NODE_DUP_TREE_MAX_ENTRIES
```
    Deprecated. this property no longer has any effect; DatabaseConfig.setNodeMaxEntries(int) should be used instead.
    
    See Also:
    
    Constant Field Values
  - TREE_MAX_EMBEDDED_LN
```
public static final java.lang.String TREE_MAX_EMBEDDED_LN
```
    The maximum size (in bytes) of a record's data portion that will cause the record to be embedded in its parent LN.
    Normally, records (key-value pairs) are stored on disk as individual byte sequences called LNs (leaf nodes) and they are accessed via a Btree. The nodes of the Btree are called INs (Internal Nodes) and the INs at the bottom layer of the Btree are called BINs (Bottom Internal Nodes). Conceptually, each BIN contains an array of slots. A slot represents an associated data record. Among other things, it stores the key of the record and the most recent disk address of that record. Records and INs share the disk space (are stored in the same kind of files), but LNs are stored separately from BINs, i.e., there is no clustering or co-location of a BIN and its child LNs.
    With embedded LNs, a whole record may be stored inside a BIN (i.e., a BIN slot may contain both the key and the data portion of a record). Specifically, a record will be "embedded" if the size (in bytes) of its data portion is less than or equal to the value of the TREE_MAX_EMBEDDED_LN configuration parameter. The decision to embed a record or not is taken on a record-by-record basis. As a result, a BIN may contain both embedded and non-embedded records. The "embeddedness" of a record is a dynamic property: a size-changing update may turn a non-embedded record to an embedded one or vice-versa.
    Notice that even though a record may be embedded, when the record is inserted, updated, or deleted an LN for that record is still generated and written to disk. This is because LNs also act as log records, which are needed during recovery and/or transaction abort to undo/redo operations that are/are-not currently reflected in the BINs. However, during normal processing, these LNs will never be fetched from disk.
    Obviously, embedding records has the performance advantage that no extra disk read is needed to fetch the record data (i.e., the LN) during read operations. This is especially true for operations like cursor scans and for random searches within key ranges whose containing BINs can fit in the JE cache (in other words when there is locality of reference). Furthermore, embedded records do not need to be migrated during cleaning; they are considered obsolete by default, because they will never be needed again after their containing log file is deleted. This makes cleaning faster, and more importantly, avoids the dirtying of the parent BINs, which would otherwise cause even more cleaning later.
    On the other hand, embedded LNs make the BINs larger, which can lead to more cache eviction of BINs and the associated performance problems. When eviction does occur, performance can deteriorate as the size of the data portion of the records grows. This is especially true for insertion-only workloads. Therefore, increasing the value of TREE_MAX_EMBEDDED_LN beyond the default value of 16 bytes should be done "carefully": by considering the kind of workloads that will be run against BDB-JE and their relative importance and expected response times, and by running performance tests with both embedded and non-embedded LNs.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.tree.maxEmbeddedLN" Integer No 16 0 Integer.MAX_VALUE
    
    See Also:
    
    Cache Statistics: Size Optimizations, Constant Field Values
  - TREE_MAX_DELTA
```
public static final java.lang.String TREE_MAX_DELTA
```
    Deprecated. as of JE 6.0. The TREE_BIN_DELTA param alone now determines whether a delta is logged.
    
    See Also:
    
    Constant Field Values
  - TREE_BIN_DELTA
```
public static final java.lang.String TREE_BIN_DELTA
```
    If more than this percentage of entries are changed on a BIN, log a a full version instead of a delta.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.tree.binDelta" Integer No 25 0 75
    
    See Also:
    
    Constant Field Values
  - TREE_MIN_MEMORY
```
public static final java.lang.String TREE_MIN_MEMORY
```
    The minimum bytes allocated out of the memory cache to hold Btree data including internal nodes and record keys and data. If the specified value is larger than the size initially available in the cache, it will be truncated to the amount available.
    TREE_MIN_MEMORY is the minimum for a single environment. By default, 500 KB or the size initially available in the cache is used, whichever is smaller.
    
    This param is only likely to be needed for tuning of Environments with extremely small cache sizes. It is sometimes also useful for debugging and testing.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.tree.minMemory" Long Yes 512000 (500K) 51200 (50K) -none-
    
    See Also:
    
    Cache Statistics: Debugging, Constant Field Values
  - TREE_COMPACT_MAX_KEY_LENGTH
```
public static final java.lang.String TREE_COMPACT_MAX_KEY_LENGTH
```
    Specifies the maximum unprefixed key length for use in the compact in-memory key representation.
    In the Btree, the JE in-memory cache, the default representation for keys uses a byte array object per key. The per-key object overhead of this approach ranges from 20 to 32 bytes, depending on the JVM platform.
    
    To reduce memory overhead, a compact representation can instead be used where keys will be represented inside a single byte array instead of having one byte array per key. Within the single array, all keys are assigned a storage size equal to that taken up by the largest key, plus one byte to hold the actual key length. The use of the fixed size array reduces Java GC activity as well as memory overhead.
    
    In order for the compact representation to reduce memory usage, all keys in a database, or in a Btree internal node, must be roughly the same size. The more fully populated the internal node, the more the savings with this representation since the single byte array is sized to hold the maximum number of keys in the internal node, regardless of the actual number of keys that are present.
    
    It's worth noting that the storage savings of the compact representation are realized in addition to the storage benefits of key prefixing (if it is configured), since the keys stored in the key array are the smaller key values after the prefix has been stripped, reducing the length of the key and making it more likely that it's small enough for this specialized representation. This configuration parameter (TREE_COMPACT_MAX_KEY_LENGTH) is the maximum key length, not including the common prefix, for the keys in a Btree internal node stored using the compact representation. See DatabaseConfig.setKeyPrefixing(boolean).
    
    The compact representation is used automatically when both of the following conditions hold.
    - All keys in a Btree internal node must have an unprefixed length that is less than or equal to the length specified by this parameter (TREE_COMPACT_MAX_KEY_LENGTH).
    - If key lengths vary by large amounts within an internal node, the wasted space of the fixed length storage may negate the benefits of the compact representation and cause more memory to be used than with the default representation. In that case, the default representation will be used.
    If this configuration parameter is set to zero, the compact representation will not be used.
    
    The default value of this configuration parameter is 16 bytes. The potential drawbacks of specifying a larger length are:
    - Insertion and deletion for larger keys move bytes proportional to the storage length of the keys.
    - With the compact representation, all operations create temporary byte arrays for each key involved in the operation. Larger byte arrays mean more work for the Java GC, even though these objects are short lived.
    Mutation of the key representation between the default and compact approaches is automatic on a per-Btree internal node basis. For example, if a key that exceeds the configured length is added to a node that uses the compact representation, the node is automatically mutated to the default representation. A best effort is made to prevent frequent mutations that could increase Java GC activity.
    
    To determine how often the compact representation is used in a running application, see EnvironmentStats.getNINCompactKeyIN().
    
    Name Type Mutable Default Minimum Maximum
    
    "je.tree.compactMaxKeyLength" Integer No 16 0 256
    Since:
    
    5.0
    
    See Also:
    
    DatabaseConfig.setKeyPrefixing(boolean), EnvironmentStats.getNINCompactKeyIN(), Cache Statistics: Size Optimizations, Constant Field Values
  - COMPRESSOR_WAKEUP_INTERVAL
```
public static final java.lang.String COMPRESSOR_WAKEUP_INTERVAL
```
    The compressor thread wakeup interval in microseconds.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.compressor.wakeupInterval" Duration No 5 s 1 s 75 min
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - COMPRESSOR_DEADLOCK_RETRY
```
public static final java.lang.String COMPRESSOR_DEADLOCK_RETRY
```
    The number of times to retry a compression run if a deadlock occurs.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.compressor.deadlockRetry" Integer No 3 0 -none-
    
    See Also:
    
    Constant Field Values
  - COMPRESSOR_LOCK_TIMEOUT
```
public static final java.lang.String COMPRESSOR_LOCK_TIMEOUT
```
    The lock timeout for compressor transactions in microseconds.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.compressor.lockTimeout" Duration No 500 ms 0 75 min
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - COMPRESSOR_PURGE_ROOT
```
public static final java.lang.String COMPRESSOR_PURGE_ROOT
```
    Deprecated. as of 3.3.87. Compression of the root node no longer has any benefit and this feature has been removed. This parameter has no effect.
    
    See Also:
    
    Constant Field Values
  - EVICTOR_EVICT_BYTES
```
public static final java.lang.String EVICTOR_EVICT_BYTES
```
    When eviction occurs, the evictor will push memory usage to this number of bytes below MAX_MEMORY. No more than 50% of je.maxMemory will be evicted per eviction cycle, regardless of this setting.
    When using the shared cache feature, the value of this property is applied the first time the cache is set up. New environments that join the cache do not alter the cache setting.
    
    This parameter impacts how often background evictor threads are awoken as well as the size of latency spikes caused by critical eviction.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.evictor.evictBytes" Long No 524288 (512K) 1024 (1K) -none-
    
    See Also:
    
    Cache Statistics: Eviction, Cache Statistics: Critical Eviction, Constant Field Values
  - EVICTOR_NODES_PER_SCAN
```
public static final java.lang.String EVICTOR_NODES_PER_SCAN
```
    Deprecated. as of JE 6.0. This parameter is ignored by the new, more efficient and more accurate evictor.
    
    See Also:
    
    Constant Field Values
  - EVICTOR_CRITICAL_PERCENTAGE
```
public static final java.lang.String EVICTOR_CRITICAL_PERCENTAGE
```
    At this percentage over the allotted cache, critical eviction will start. For example, if this parameter is 5, then when the cache size is 5% over its maximum or 105% full, critical eviction will start.
    Critical eviction is eviction performed in application threads as part of normal database access operations. Background eviction, on the other hand, is performed in JE evictor threads as well as during log cleaning and checkpointing. Background eviction is unconditionally started when the cache size exceeds its maximum. When critical eviction is also performed (concurrently with background eviction), it helps to ensure that the cache size does not continue to grow, but can have a negative impact on operation latency.
    By default this parameter is zero, which means that critical eviction will start as soon as the cache size exceeds its maximum. Some applications may wish to set this parameter to a non-zero value to improve operation latency, when eviction is a significant performance factor and latency requirements are not being satisfied.
    When setting this parameter to a non-zero value, for example 5, be sure to reserve enough heap memory for the cache size to be over its configured maximum, for example 105% full.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.evictor.criticalPercentage" Integer No 0 0 1000
    
    See Also:
    
    Cache Statistics: Critical Eviction, Constant Field Values
  - EVICTOR_DEADLOCK_RETRY
```
public static final java.lang.String EVICTOR_DEADLOCK_RETRY
```
    Deprecated. as of JE 4.1, since the single evictor thread has been replaced be a more robust thread pool.
    
    See Also:
    
    Constant Field Values
  - EVICTOR_LRU_ONLY
```
public static final java.lang.String EVICTOR_LRU_ONLY
```
    Deprecated. as of JE 6.0. This parameter is ignored by the new, more efficient and more accurate evictor.
    
    See Also:
    
    Constant Field Values
  - EVICTOR_N_LRU_LISTS
```
public static final java.lang.String EVICTOR_N_LRU_LISTS
```
    The number of LRU lists in the main JE cache.
    Ideally, all nodes managed by an LRU eviction policy should appear in a single LRU list, ordered by the "hotness" of each node. However, such a list is accessed very frequently by multiple threads, and can become a synchronization bottleneck. To avoid this problem, the evictor can employ multiple LRU lists. The nLRULists parameter specifies the number of LRU lists to be used. Increasing the number of LRU lists alleviates any potential synchronization bottleneck, but it also decreases the quality of the LRU approximation.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.evictor.nLRULists" Integer No 4 1 32
    
    See Also:
    
    Cache Statistics: LRU List Contention, Constant Field Values
  - EVICTOR_FORCED_YIELD
```
public static final java.lang.String EVICTOR_FORCED_YIELD
```
    Call Thread.yield() at each check for cache overflow. This potentially improves GC performance, but little testing has been done and the actual benefit is unknown.
    When using the shared cache feature, the value of this property is applied the first time the cache is set up. New environments that join the cache do not alter the cache setting.
    
    This param is unlikely to be needed for tuning, but is sometimes useful for debugging and testing.
    
    Name Type Mutable Default
    
    "je.evictor.forcedYield" Boolean No false
    
    See Also:
    
    Cache Statistics: Debugging, Constant Field Values
  - EVICTOR_CORE_THREADS
```
public static final java.lang.String EVICTOR_CORE_THREADS
```
    The minimum number of threads in the eviction thread pool.
    These threads help keep memory usage within cache bounds, offloading work from application threads.
    EVICTOR_CORE_THREADS, EVICTOR_MAX_THREADS and EVICTOR_KEEP_ALIVE are used to configure the core, max and keepalive attributes for the ThreadPoolExecutor which implements the eviction thread pool.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.evictor.coreThreads" Integer yes 1 0 Integer.MAX_VALUE
    
    See Also:
    
    Constant Field Values
  - EVICTOR_MAX_THREADS
```
public static final java.lang.String EVICTOR_MAX_THREADS
```
    The maximum number of threads in the eviction thread pool.
    These threads help keep memory usage within cache bound, offloading work from application threads. If the eviction thread pool receives more work, it will allocate up to this number of threads. These threads will terminate if they are idle for more than the time indicated by EVICTOR_KEEP_ALIVE.
    EVICTOR_CORE_THREADS, EVICTOR_MAX_THREADS and EVICTOR_KEEP_ALIVE are used to configure the core, max and keepalive attributes for the ThreadPoolExecutor which implements the eviction thread pool.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.evictor.maxThreads" Integer yes 10 1 Integer.MAX_VALUE
    
    See Also:
    
    Constant Field Values
  - EVICTOR_KEEP_ALIVE
```
public static final java.lang.String EVICTOR_KEEP_ALIVE
```
    The duration that excess threads in the eviction thread pool will stay idle; after this period, idle threads will terminate.
    EVICTOR_CORE_THREADS, EVICTOR_MAX_THREADS and EVICTOR_KEEP_ALIVE are used to configure the core, max and keepalive attributes for the ThreadPoolExecutor which implements the eviction thread pool.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.evictor.keepAlive" Duration Yes 10 min 1 s 1 d
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - EVICTOR_ALLOW_BIN_DELTAS
```
public static final java.lang.String EVICTOR_ALLOW_BIN_DELTAS
```
    Allow Bottom Internal Nodes (BINs) to be written in a delta format during eviction. Using a delta format will improve write and log cleaning performance. There is no known performance benefit to setting this parameter to false.
    This param is unlikely to be needed for tuning, but is sometimes useful for debugging and testing.
    
    Name Type Mutable Default
    
    "je.evictor.allowBinDeltas" Boolean No true
    
    See Also:
    
    Cache Statistics: Debugging, Constant Field Values
  - OFFHEAP_EVICT_BYTES
```
public static final java.lang.String OFFHEAP_EVICT_BYTES
```
    The off-heap evictor will attempt to keep memory usage this number of bytes below MAX_OFF_HEAP_MEMORY.
    If this value is too small, memory usage may exceed the maximum and then "critical eviction" is needed, which will increase operation latency in the application threads.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.offHeap.evictBytes" Long No 52428800 (50MB) 1024 (1K) -none-
    
    See Also:
    
    Cache Statistics: Critical Eviction, Constant Field Values
  - OFFHEAP_N_LRU_LISTS
```
public static final java.lang.String OFFHEAP_N_LRU_LISTS
```
    The number of LRU lists in the off-heap JE cache.
    Ideally, all nodes managed by an LRU eviction policy should appear in a single LRU list, ordered by the "hotness" of each node. However, such a list is accessed very frequently by multiple threads, and can become a synchronization bottleneck. To avoid this problem, the evictor can employ multiple LRU lists. The nLRULists parameter specifies the number of LRU lists to be used. Increasing the number of LRU lists alleviates any potential synchronization bottleneck, but it also decreases the quality of the LRU approximation.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.evictor.nLRULists" Integer No 4 1 32
    
    See Also:
    
    Cache Statistics: LRU List Contention, Constant Field Values
  - OFFHEAP_CHECKSUM
```
public static final java.lang.String OFFHEAP_CHECKSUM
```
    Can be used to add a checksum to each off-heap block when the block is written, and validate the checksum when the block is read, for debugging purposes. Setting this param to true adds memory and CPU overhead, and it should normally be set to false in a production environment.
    
    Name Type Mutable Default
    
    "je.offHeap.checksum" Boolean No false
    
    See Also:
    
    Cache Statistics: Debugging, Constant Field Values
  - OFFHEAP_CORE_THREADS
```
public static final java.lang.String OFFHEAP_CORE_THREADS
```
    The minimum number of threads in the off-heap eviction thread pool.
    These threads help keep memory usage within cache bounds, offloading work from application threads.
    OFFHEAP_CORE_THREADS, OFFHEAP_MAX_THREADS and OFFHEAP_KEEP_ALIVE are used to configure the core, max and keepalive attributes for the ThreadPoolExecutor which implements the eviction thread pool.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.offHeap.coreThreads" Integer yes 1 0 Integer.MAX_VALUE
    
    See Also:
    
    Constant Field Values
  - OFFHEAP_MAX_THREADS
```
public static final java.lang.String OFFHEAP_MAX_THREADS
```
    The maximum number of threads in the off-heap eviction thread pool.
    These threads help keep memory usage within cache bound, offloading work from application threads. If the eviction thread pool receives more work, it will allocate up to this number of threads. These threads will terminate if they are idle for more than the time indicated by OFFHEAP_KEEP_ALIVE.
    If the number of threads is too small, memory usage may exceed the maximum and then "critical eviction" is needed, which will increase operation latency in the application threads.
    OFFHEAP_CORE_THREADS, OFFHEAP_MAX_THREADS and OFFHEAP_KEEP_ALIVE are used to configure the core, max and keepalive attributes for the ThreadPoolExecutor which implements the eviction thread pool.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.offHeap.maxThreads" Integer yes 3 1 Integer.MAX_VALUE
    
    See Also:
    
    Constant Field Values
  - OFFHEAP_KEEP_ALIVE
```
public static final java.lang.String OFFHEAP_KEEP_ALIVE
```
    The duration that excess threads in the off-heap eviction thread pool will stay idle; after this period, idle threads will terminate.
    OFFHEAP_CORE_THREADS, OFFHEAP_MAX_THREADS and OFFHEAP_KEEP_ALIVE are used to configure the core, max and keepalive attributes for the ThreadPoolExecutor which implements the eviction thread pool.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.offHeap.keepAlive" Duration Yes 10 min 1 s 1 d
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - CHECKPOINTER_BYTES_INTERVAL
```
public static final java.lang.String CHECKPOINTER_BYTES_INTERVAL
```
    Ask the checkpointer to run every time we write this many bytes to the log. If set, supersedes CHECKPOINTER_WAKEUP_INTERVAL. To use time based checkpointing, set this to 0.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.checkpointer.bytesInterval" Long No 20000000 (20M) 0 -none-
    
    See Also:
    
    Constant Field Values
  - CHECKPOINTER_WAKEUP_INTERVAL
```
public static final java.lang.String CHECKPOINTER_WAKEUP_INTERVAL
```
    The checkpointer wakeup interval in microseconds. By default, this is inactive and we wakeup the checkpointer as a function of the number of bytes written to the log (CHECKPOINTER_BYTES_INTERVAL).
    
    Name Type Mutable Default Minimum Maximum
    
    "je.checkpointer.wakeupInterval" Duration No 0 1 s 75 min
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - CHECKPOINTER_DEADLOCK_RETRY
```
public static final java.lang.String CHECKPOINTER_DEADLOCK_RETRY
```
    The number of times to retry a checkpoint if it runs into a deadlock.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.checkpointer.deadlockRetry" Integer No 3 0 -none-
    
    See Also:
    
    Constant Field Values
  - CHECKPOINTER_HIGH_PRIORITY
```
public static final java.lang.String CHECKPOINTER_HIGH_PRIORITY
```
    If true, the checkpointer uses more resources in order to complete the checkpoint in a shorter time interval. Btree latches are held and other threads are blocked for a longer period. When set to true, application response time may be longer during a checkpoint.
    
    Name Type Mutable Default
    
    "je.checkpointer.highPriority" Boolean Yes false
    
    See Also:
    
    Constant Field Values
  - CLEANER_MIN_UTILIZATION
```
public static final java.lang.String CLEANER_MIN_UTILIZATION
```
    The cleaner will keep the total disk space utilization percentage above this value.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.minUtilization" Integer Yes 50 0 90
    
    See Also:
    
    Constant Field Values
  - CLEANER_MIN_FILE_UTILIZATION
```
public static final java.lang.String CLEANER_MIN_FILE_UTILIZATION
```
    A log file will be cleaned if its utilization percentage is below this value, irrespective of total utilization.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.minFileUtilization" Integer Yes 5 0 50
    
    See Also:
    
    Constant Field Values
  - CLEANER_BYTES_INTERVAL
```
public static final java.lang.String CLEANER_BYTES_INTERVAL
```
    The cleaner checks disk utilization every time we write this many bytes to the log. If zero (and by default) it is set to either the LOG_FILE_MAX value divided by four, or to 100 MB, whichever is smaller.
    When overriding the default value, use caution to ensure that the cleaner is woken frequently enough, so that reserved files are deleted quickly enough to avoid violating a disk limit.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.bytesInterval" Long Yes 0 0 -none-
    
    See Also:
    
    CLEANER_WAKEUP_INTERVAL, Constant Field Values
  - CLEANER_WAKEUP_INTERVAL
```
public static final java.lang.String CLEANER_WAKEUP_INTERVAL
```
    The cleaner checks whether cleaning is needed if this interval elapses without any writing, to handle the case where cleaning or checkpointing is necessary to reclaim disk space, but writing has stopped. This addresses the problem that CLEANER_BYTES_INTERVAL may not cause cleaning, and CHECKPOINTER_BYTES_INTERVAL may not cause checkpointing, when enough writing has not occurred to exceed these intervals.
    If this parameter is set to zero, the cleaner wakeup interval is disabled, and cleaning and checkpointing will occur only via CLEANER_BYTES_INTERVAL, CHECKPOINTER_BYTES_INTERVAL, and CHECKPOINTER_WAKEUP_INTERVAL.
    
    For example, if a database were removed or truncated, or large records were deleted, the amount written to the log may not exceed CLEANER_BYTES_INTERVAL. If writing were to stop at that point, no cleaning would occur, if it were not for the wakeup interval.
    
    In addition, even when cleaning is performed, a checkpoint is additionally needed to reclaim disk space. This may not occur if CHECKPOINTER_BYTES_INTERVAL or CHECKPOINTER_WAKEUP_INTERVAL does not happen to cause a checkpoint after write operations have stopped. If files have been cleaned and a checkpoint is needed to reclaim space, and write operations have stopped, a checkpoint will be scheduled when the CLEANER_WAKEUP_INTERVAL elapses. The checkpoint will be performed in the JE checkpointer thread if it is not disabled, or when Environment.checkpoint(com.sleepycat.je.CheckpointConfig) is called.
    
    In test environments it is fairly common for application writing to stop, and then to expect cleaning to occur as a result of the last set of operations. This situation may also arise in production environments, for example, during repair of an out-of-disk situation.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.wakeupInterval" Duration Yes 10 s 0 10 h
    
    Since:
    
    7.1
    
    See Also:
    
    Time Duration Properties, CLEANER_BYTES_INTERVAL, Constant Field Values
  - CLEANER_FETCH_OBSOLETE_SIZE
```
public static final java.lang.String CLEANER_FETCH_OBSOLETE_SIZE
```
    If true, the cleaner will fetch records to determine their size and more accurately calculate log utilization. Normally when a record is updated or deleted without first being read (sometimes called a blind delete/update), the size of the previous version of the record is unknown and therefore the cleaner's utilization calculations may be incorrect. Setting this parameter to true will cause a record to be read during a blind delete/update, in order to determine its size. This will ensure that the cleaner's utilization calculations are correct, but will cause more (potentially random) IO.
    
    Name Type Mutable Default
    
    "je.cleaner.fetchObsoleteSize" Boolean Yes false
    
    See Also:
    
    CLEANER_ADJUST_UTILIZATION, Constant Field Values
  - CLEANER_ADJUST_UTILIZATION
```
public static final java.lang.String CLEANER_ADJUST_UTILIZATION
```
    Deprecated. in JE 6.3. Adjustments are no longer needed because LN log sizes have been stored in the Btree since JE 6.0.
    
    See Also:
    
    Constant Field Values
  - CLEANER_DEADLOCK_RETRY
```
public static final java.lang.String CLEANER_DEADLOCK_RETRY
```
    The number of times to retry cleaning if a deadlock occurs.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.deadlockRetry" Integer Yes 3 0 -none-
    
    See Also:
    
    Constant Field Values
  - CLEANER_LOCK_TIMEOUT
```
public static final java.lang.String CLEANER_LOCK_TIMEOUT
```
    The lock timeout for cleaner transactions in microseconds.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.lockTimeout" Duration Yes 500 ms 0 75 min
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - CLEANER_EXPUNGE
```
public static final java.lang.String CLEANER_EXPUNGE
```
    If true (the default setting), the cleaner deletes log files after successful cleaning. This parameter may be set to false for diagnosing log cleaning problems. For example, if a bug causes a LOG_FILE_NOT_FOUND exception, when reproducing the problem it is often necessary to avoid deleting files so they can be used for diagnosis. When this parameter is false:
    - Rather than delete files that are successfully cleaned, the cleaner renames them.
    - When renaming a file, its extension is changed from ".jdb" to ".del" and its last modification date is set to the current time.
    - Depending on the setting of the CLEANER_USE_DELETED_DIR parameter, the file is either renamed in its current data directory (the default), or moved into the "deleted" sub-directory.
    When this parameter is set to false, disk usage may grow without bounds and the application is responsible for removing the cleaned files. It may be necessary to write a script for deleting the least recently cleaned files when disk usage is low. The .del extension and the last modification time can be leveraged to write such a script. The "deleted" sub-directory can be used to avoid granting write or delete permissions for the main data directory to the script.
    
    Name Type Mutable Default
    
    "je.cleaner.expunge" Boolean Yes true
    See Also:
    
    Constant Field Values
  - CLEANER_USE_DELETED_DIR
```
public static final java.lang.String CLEANER_USE_DELETED_DIR
```
    When CLEANER_EXPUNGE is false, the CLEANER_USE_DELETED_DIR parameter determines whether successfully cleaned files are moved to the "deleted" sub-directory. CLEANER_USE_DELETED_DIR applies only when CLEANER_EXPUNGE is false. When CLEANER_EXPUNGE is true, successfully cleaned files are deleted and the CLEANER_USE_DELETED_DIR parameter setting is ignored.
    When CLEANER_USE_DELETED_DIR is true (and CLEANER_EXPUNGE is false), the cleaner will move successfully cleaned data files (".jdb" files) to the "deleted" sub-directory of the Environment directory, in addition to changing the file extension to "*.del". In this case, the "deleted" sub-directory must have been created by the application before opening the Environment. This allows the application to control permissions on this sub-directory. When multiple data directories are used (LOG_N_DATA_DIRECTORIES), a "deleted" sub-directory must be created under each data directory. Note that File.renameTo(File) is used to move the file, and this method may or may not support moving the file to a different volume (when the "deleted" directory is a file system link) on a particular platform.
    When CLEANER_USE_DELETED_DIR is false (and CLEANER_EXPUNGE is false), the cleaner will change the file extension of successfully cleaned data files from ".jdb" to ".del", but will not move the files to a different directory.
    
    Name Type Mutable Default
    
    "je.cleaner.useDeletedDir" Boolean Yes false
    
    See Also:
    
    Constant Field Values
  - CLEANER_MIN_AGE
```
public static final java.lang.String CLEANER_MIN_AGE
```
    The minimum age of a file (number of files between it and the active file) to qualify it for cleaning under any conditions.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.minAge" Integer Yes 2 1 1000
    
    See Also:
    
    Constant Field Values
  - CLEANER_MAX_BATCH_FILES
```
public static final java.lang.String CLEANER_MAX_BATCH_FILES
```
    Deprecated. in 7.0. No longer used because the cleaner no longer has a backlog.
    
    See Also:
    
    Constant Field Values
  - CLEANER_READ_SIZE
```
public static final java.lang.String CLEANER_READ_SIZE
```
    The read buffer size for cleaning. If zero (the default), then LOG_ITERATOR_READ_SIZE value is used.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.readSize" Integer Yes 0 128 -none-
    
    See Also:
    
    Constant Field Values
  - CLEANER_DETAIL_MAX_MEMORY_PERCENTAGE
```
public static final java.lang.String CLEANER_DETAIL_MAX_MEMORY_PERCENTAGE
```
    Tracking of detailed cleaning information will use no more than this percentage of the cache. The default value is 2% of MAX_MEMORY. If 0 and SHARED_CACHE is true, use 2% divided by N where N is the number of environments sharing the global cache.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.detailMaxMemoryPercentage" Integer Yes 2 1 90
    
    See Also:
    
    Constant Field Values
  - CLEANER_FORCE_CLEAN_FILES
```
public static final java.lang.String CLEANER_FORCE_CLEAN_FILES
```
    Specifies a list of files or file ranges to be cleaned at a time when no other log cleaning is necessary. This parameter is intended for use in forcing the cleaning of a large number of log files. File numbers are in hex and are comma separated or hyphen separated to specify ranges, e.g.: '9,a,b-d' will clean 5 files.
    
    Name Type Mutable Default
    
    "je.cleaner.forceCleanFiles" String No ""
    
    See Also:
    
    Constant Field Values
  - CLEANER_UPGRADE_TO_LOG_VERSION
```
public static final java.lang.String CLEANER_UPGRADE_TO_LOG_VERSION
```
    All log files having a log version prior to the specified version will be cleaned at a time when no other log cleaning is necessary. Intended for use in upgrading old format log files forward to the current log format version, e.g., to take advantage of format improvements; note that log upgrading is optional. The default value zero (0) specifies that no upgrading will occur. The value negative one (-1) specifies upgrading to the current log version.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.upgradeToLogVersion" Integer No 0 -1 -none-
    
    See Also:
    
    Constant Field Values
  - CLEANER_THREADS
```
public static final java.lang.String CLEANER_THREADS
```
    The number of threads allocated by the cleaner for log file processing. If the cleaner backlog becomes large, try increasing this value.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.threads" Integer Yes 1 1 -none-
    
    See Also:
    
    Constant Field Values
  - CLEANER_LOOK_AHEAD_CACHE_SIZE
```
public static final java.lang.String CLEANER_LOOK_AHEAD_CACHE_SIZE
```
    The look ahead cache size for cleaning in bytes. Increasing this value can reduce the number of Btree lookups.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.cleaner.lookAheadCacheSize" Integer Yes 8192 (8K) 0 -none-
    
    See Also:
    
    Constant Field Values
  - CLEANER_FOREGROUND_PROACTIVE_MIGRATION
```
public static final java.lang.String CLEANER_FOREGROUND_PROACTIVE_MIGRATION
```
    Deprecated. This parameter is ignored and proactive migration is no longer supported due to its negative impact on eviction and Btree splits. To reduce a cleaner backlog, configure more cleaner threads.
    
    See Also:
    
    Constant Field Values
  - CLEANER_BACKGROUND_PROACTIVE_MIGRATION
```
public static final java.lang.String CLEANER_BACKGROUND_PROACTIVE_MIGRATION
```
    Deprecated. This parameter is ignored and proactive migration is no longer supported due to its negative impact on eviction and checkpointing. To reduce a cleaner backlog, configure more cleaner threads.
    
    See Also:
    
    Constant Field Values
  - CLEANER_LAZY_MIGRATION
```
public static final java.lang.String CLEANER_LAZY_MIGRATION
```
    Deprecated. This parameter is ignored and lazy migration is no longer supported due to its negative impact on eviction and checkpointing. To reduce a cleaner backlog, configure more cleaner threads.
    
    See Also:
    
    Constant Field Values
  - DOS_PRODUCER_QUEUE_TIMEOUT
```
public static final java.lang.String DOS_PRODUCER_QUEUE_TIMEOUT
```
    The timeout for Disk Ordered Scan producer thread queue offers in milliseconds.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.diskOrderedScanLockTimeout" Duration Yes 10 secs 0 75 min
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - LOCK_N_LOCK_TABLES
```
public static final java.lang.String LOCK_N_LOCK_TABLES
```
    Number of Lock Tables. Set this to a value other than 1 when an application has multiple threads performing concurrent JE operations. It should be set to a prime number, and in general not higher than the number of application threads performing JE operations.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.lock.nLockTables" Integer No 1 1 32767 (32K)
    
    See Also:
    
    Constant Field Values
  - LOCK_TIMEOUT
```
public static final java.lang.String LOCK_TIMEOUT
```
    Configures the default lock timeout. It may be overridden on a per-transaction basis by calling Transaction.setLockTimeout(long, TimeUnit).
    A value of zero disables lock timeouts. This is not recommended, even when the application expects that deadlocks will not occur or will be easily resolved. A lock timeout is a fall-back that guards against unexpected "live lock", unresponsive threads, or application failure to close a cursor or to commit or abort a transaction.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.lock.timeout" Duration No 500 ms 0 75 min
    
    See Also:
    
    setLockTimeout(long,TimeUnit), Time Duration Properties, Constant Field Values
  - LOCK_DEADLOCK_DETECT
```
public static final java.lang.String LOCK_DEADLOCK_DETECT
```
    Whether to perform deadlock detection when a lock conflict occurs. By default, deadlock detection is enabled (this parameter is true) in order to reduce thread wait times when there are deadlocks.
    Deadlock detection is performed as follows.
    1. When a lock is requested by a record read or write operation, JE checks for lock conflicts with another transaction or another thread performing a non-transactional operation. If there is no conflict, the lock is acquired and the operation returns normally.
    2. When there is a conflict, JE performs deadlock detection. However, before performing deadlock detection, JE waits for the LOCK_DEADLOCK_DETECT_DELAY interval, if it is non-zero. This delay is useful for avoiding the overhead of deadlock detection when normal, short-lived contention (not a deadlock) is the reason for the conflict. If the lock is acquired during the delay, the thread wakes up and the operation returns normally.
    3. If a deadlock is detected, DeadlockException is thrown in one of the threads participating in the deadlock, called the "victim". The victim is chosen at random to prevent a repeated pattern of deadlocks, called "live lock". A non-victim thread that detects a deadlock will notify the victim and perform short delays, waiting for the deadlock to be broken; if the lock is acquired, the operation returns normally.
    4. It is possible for live lock to occur in spite of using random victim selection. It is also possible that a deadlock is not broken because the victim thread is unresponsive or the application fails to close a cursor or to commit or abort a transaction. In these cases, if the lock or transaction timeout expires without acquiring the lock, a DeadlockException is thrown for the last deadlock detected, in the thread that detected the deadlock. In this case, DeadlockException may be thrown by more than one thread participating in the deadlock.
    5. When no deadlock is detected, JE waits for the lock or transaction timeout to expire. If the lock is acquired during this delay, the thread wakes up and the operation returns normally.
    6. When the lock or transaction timeout expires without acquiring the lock, JE checks for deadlocks one final time. If a deadlock is detected, DeadlockException is thrown; otherwise, LockTimeoutException or TransactionTimeoutExceptionis thrown.
    Deadlock detection may be disabled (by setting this parameter to false) in applications that are known to be free of deadlocks, and this may provide a slight performance improvement in certain scenarios. However, this is not recommended because deadlock-free operation is difficult to guarantee. If deadlock detection is disabled, JE skips steps 2, 3 and 4 above. However, deadlock detection is always performed in the last step, and DeadlockException may be thrown.
    
    Name Type Mutable Default
    
    "je.lock.deadlockDetect" Boolean No true
    Since:
    
    7.1
    
    See Also:
    
    Constant Field Values
  - LOCK_DEADLOCK_DETECT_DELAY
```
public static final java.lang.String LOCK_DEADLOCK_DETECT_DELAY
```
    The delay after a lock conflict, before performing deadlock detection. This delay is used to avoid the overhead of deadlock detection when normal contention (not a deadlock) is the reason for the conflict. See LOCK_DEADLOCK_DETECT for more information.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.lock.deadlockDetectDelay" Duration No 0 0 75 min
    
    Since:
    
    7.1
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - LOCK_OLD_LOCK_EXCEPTIONS
```
public static final java.lang.String LOCK_OLD_LOCK_EXCEPTIONS
```
    Deprecated. since JE 6.5; has no effect, as if it were set to false.
    
    Used in JE releases 3.4 through 6.4 to throw old-style lock exceptions for compatibility with JE release 3.3 and earlier.
    
    See Also:
    
    Constant Field Values
  - TXN_TIMEOUT
```
public static final java.lang.String TXN_TIMEOUT
```
    Configures the transaction timeout.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.txn.timeout" Duration No 0 0 75 min
    
    See Also:
    
    setTxnTimeout(long, java.util.concurrent.TimeUnit), Time Duration Properties, Constant Field Values
  - TXN_SERIALIZABLE_ISOLATION
```
public static final java.lang.String TXN_SERIALIZABLE_ISOLATION
```
    Configures all transactions for this environment to have Serializable (Degree 3) isolation. By setting Serializable isolation, phantoms will be prevented. By default transactions provide Repeatable Read isolation. The default is false for the database environment.
    
    Name Type Mutable Default
    
    "je.txn.serializableIsolation" Boolean No false
    
    See Also:
    
    setTxnSerializableIsolation(boolean), Constant Field Values
  - TXN_DURABILITY
```
public static final java.lang.String TXN_DURABILITY
```
    Configures the default durability associated with transactions.
    
    Name Type Mutable Default
    
    "je.txn.durability" String Yes null
    
    The format of the durability string is described at Durability.parse(String)
    
    See Also:
    
    Durability, EnvironmentMutableConfig.setDurability(com.sleepycat.je.Durability), Constant Field Values
  - TXN_DEADLOCK_STACK_TRACE
```
public static final java.lang.String TXN_DEADLOCK_STACK_TRACE
```
    Set this parameter to true to add stacktrace information to deadlock (lock timeout) exception messages. The stack trace will show where each lock was taken. The default is false, and true should only be used during debugging because of the added memory/processing cost. This parameter is 'static' across all environments.
    
    Name Type Mutable Default
    
    "je.txn.deadlockStackTrace" Boolean Yes false
    
    See Also:
    
    Constant Field Values
  - TXN_DUMP_LOCKS
```
public static final java.lang.String TXN_DUMP_LOCKS
```
    Dump the lock table when a lock timeout is encountered, for debugging assistance.
    
    Name Type Mutable Default
    
    "je.txn.dumpLocks" Boolean Yes false
    
    See Also:
    
    Constant Field Values
  - TRACE_FILE
```
public static final java.lang.String TRACE_FILE
```
    Deprecated. in favor of FILE_LOGGING_LEVEL As of JE 4.0, use the standard java.util.logging configuration methodologies. To enable logging output to the je.info files, set com.sleepycat.je.util.FileHandler.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager. To set the handler level programmatically, set "com.sleepycat.je.util.FileHandler.level" in the EnvironmentConfig object.
    
    See Also:
    
    Constant Field Values
  - TRACE_CONSOLE
```
public static final java.lang.String TRACE_CONSOLE
```
    Deprecated. in favor of CONSOLE_LOGGING_LEVEL As of JE 4.0, use the standard java.util.logging configuration methodologies. To enable console output, set com.sleepycat.je.util.ConsoleHandler.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager. To set the handler level programmatically, set "com.sleepycat.je.util.ConsoleHandler.level" in the EnvironmentConfig object.
    
    See Also:
    
    Constant Field Values
  - TRACE_DB
```
public static final java.lang.String TRACE_DB
```
    Deprecated. As of JE 4.0, event tracing to the .jdb files has been separated from the java.util.logging mechanism. This parameter has no effect.
    
    See Also:
    
    Constant Field Values
  - TRACE_FILE_LIMIT
```
public static final java.lang.String TRACE_FILE_LIMIT
```
    Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To set the FileHandler output file size, set com.sleepycat.je.util.FileHandler.limit = <NUMBER> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
    
    See Also:
    
    Constant Field Values
  - TRACE_FILE_COUNT
```
public static final java.lang.String TRACE_FILE_COUNT
```
    Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To set the FileHandler output file count, set com.sleepycat.je.util.FileHandler.count = <NUMBER> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
    
    See Also:
    
    Constant Field Values
  - TRACE_LEVEL
```
public static final java.lang.String TRACE_LEVEL
```
    Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. Set logging levels using class names through the java.util.logging configuration file, or through the java.util.logging.LogManager.
    
    See Also:
    
    Constant Field Values
  - CONSOLE_LOGGING_LEVEL
```
public static final java.lang.String CONSOLE_LOGGING_LEVEL
```
    Trace messages equal and above this level will be logged to the console. Value should be one of the predefined java.util.logging.Level values.
    Setting this parameter in the je.properties file or through setConfigParam(java.lang.String, java.lang.String) is analogous to setting the property in the java.util.logging properties file or MBean. It is preferred to use the standard java.util.logging mechanisms for configuring java.util.logging.Handler, but this JE parameter is provided because the java.util.logging API doesn't provide a method to set handler levels programmatically.
    
    Name Type Mutable Default
    
    "com.sleepycat.je.util.ConsoleHandler.level" String No "OFF"
    
    See Also:
    
    Chapter 12. Logging, Constant Field Values
  - FILE_LOGGING_LEVEL
```
public static final java.lang.String FILE_LOGGING_LEVEL
```
    Trace messages equal and above this level will be logged to the je.info file, which is in the Environment home directory. Value should be one of the predefined java.util.logging.Level values.
    Setting this parameter in the je.properties file or through setConfigParam(java.lang.String, java.lang.String) is analogous to setting the property in the java.util.logging properties file or MBean. It is preferred to use the standard java.util.logging mechanisms for configuring java.util.logging.Handler, but this JE parameter is provided because the java.util.logging APIs doesn't provide a method to set handler levels programmatically.
    
    Name Type Mutable Default
    
    "com.sleepycat.je.util.FileHandler.level" String No "INFO"
    
    See Also:
    
    Chapter 12. Logging, Constant Field Values
  - TRACE_LEVEL_LOCK_MANAGER
```
public static final java.lang.String TRACE_LEVEL_LOCK_MANAGER
```
    Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To see locking logging, set com.sleepycat.je.txn.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
    
    See Also:
    
    Constant Field Values
  - TRACE_LEVEL_RECOVERY
```
public static final java.lang.String TRACE_LEVEL_RECOVERY
```
    Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To see recovery logging, set com.sleepycat.je.recovery.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
    
    See Also:
    
    Constant Field Values
  - TRACE_LEVEL_EVICTOR
```
public static final java.lang.String TRACE_LEVEL_EVICTOR
```
    Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To see evictor logging, set com.sleepycat.je.evictor.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
    
    See Also:
    
    Constant Field Values
  - TRACE_LEVEL_CLEANER
```
public static final java.lang.String TRACE_LEVEL_CLEANER
```
    Deprecated. As of JE 4.0, use the standard java.util.logging configuration methodologies. To see cleaner logging, set com.sleepycat.je.cleaner.level = <LEVEL> through the java.util.logging configuration file, or through the java.util.logging.LogManager.
    
    See Also:
    
    Constant Field Values
  - STARTUP_DUMP_THRESHOLD
```
public static final java.lang.String STARTUP_DUMP_THRESHOLD
```
    If environment startup exceeds this duration, startup statistics are logged and can be found in the je.info file.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.env.startupThreshold" Duration No 5 min 0 none
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - STATS_COLLECT
```
public static final java.lang.String STATS_COLLECT
```
    If true collect and log statistics. The statistics are logged in CSV format and written to the log file at a user specified interval. The logging occurs per-Environment when the Environment is opened in read/write mode. Statistics are written to a filed named je.stat.csv. Successively older files are named by adding "0", "1", "2", etc into the file name. The file name format is je.stat.[version number].csv.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.stats.collect" Boolean Yes True 0 none
    
    See Also:
    
    Constant Field Values
  - STATS_MAX_FILES
```
public static final java.lang.String STATS_MAX_FILES
```
    Maximum number of statistics log files to retain. The rotating set of files, as each file reaches a given size limit, is closed, rotated out, and a new file opened. The name of the log file is je.stat.csv. Successively older files are named by adding "0", "1", "2", etc into the file name. The file name format is je.stat.[version number].csv.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.stats.max.files" Integer Yes 10 1 -none-
    
    See Also:
    
    Constant Field Values
  - STATS_FILE_ROW_COUNT
```
public static final java.lang.String STATS_FILE_ROW_COUNT
```
    Log file maximum row count for Stat collection. When the number of rows in the statistics file reaches the maximum row count, the file is closed, rotated out, and a new file opened. The name of the log file is je.stat.csv. Successively older files are named by adding "0", "1", "2", etc into the file name. The file name format is je.stat.[version number].csv.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.stats.file.row.count" Integer Yes 1440 1 -none-
    
    See Also:
    
    Constant Field Values
  - STATS_COLLECT_INTERVAL
```
public static final java.lang.String STATS_COLLECT_INTERVAL
```
    The duration of the statistics capture interval. Statistics are captured and written to the log file at this interval.
    
    Name Type Mutable Default Minimum Maximum
    
    "je.stats.collect.interval" Duration Yes 1 min 1 s 24 d
    
    See Also:
    
    Time Duration Properties, Constant Field Values
  - STATS_FILE_DIRECTORY
```
public static final java.lang.String STATS_FILE_DIRECTORY
```
    The directory to save the statistics log file.
    
    Name Type Mutable Default
    
    "je.stats.file.directory" String No "NULL-> Environment home directory"
    
    See Also:
    
    Constant Field Values
- Constructor Detail
  - EnvironmentConfig
```
public EnvironmentConfig()
```
    Creates an EnvironmentConfig initialized with the system default settings.
  - EnvironmentConfig
```
public EnvironmentConfig(java.util.Properties properties)
                  throws java.lang.IllegalArgumentException
```
    Creates an EnvironmentConfig which includes the properties specified in the properties parameter.
    
    Parameters:
    
    properties - Supported properties are described in this class
    
    Throws:
    
    java.lang.IllegalArgumentException - If any properties read from the properties param are invalid.
- Method Detail
  - setAllowCreate
```
public EnvironmentConfig setAllowCreate(boolean allowCreate)
```
    If true, creates the database environment if it doesn't already exist.
    
    Parameters:
    
    allowCreate - If true, the database environment is created if it doesn't already exist.
    
    Returns:
    
    this
  - getAllowCreate
```
public boolean getAllowCreate()
```
    Returns a flag that specifies if we may create this environment.
    
    Returns:
    
    true if we may create this environment.
  - setLockTimeout
```
public EnvironmentConfig setLockTimeout(long timeout,
                                        java.util.concurrent.TimeUnit unit)
                                 throws java.lang.IllegalArgumentException
```
    Convenience method for setting LOCK_TIMEOUT.
    
    Parameters:
    
    timeout - The lock timeout for all transactional and non-transactional operations, or zero to disable lock timeouts.
    
    unit - the TimeUnit of the timeout value. May be null only if timeout is zero.
    
    Returns:
    
    this
    
    Throws:
    
    java.lang.IllegalArgumentException - if the value of timeout is invalid
    
    See Also:
    
    LOCK_TIMEOUT, Transaction.setLockTimeout(long,TimeUnit)
  - setLockTimeout
```
public EnvironmentConfig setLockTimeout(long timeout)
                                 throws java.lang.IllegalArgumentException
```
    Deprecated. as of 4.0, replaced by setLockTimeout(long, TimeUnit).
    Configures the lock timeout, in microseconds. This method is equivalent to:
```
setLockTimeout(long, TimeUnit.MICROSECONDS);
```
    Throws:
    
    java.lang.IllegalArgumentException
  - getLockTimeout
```
public long getLockTimeout(java.util.concurrent.TimeUnit unit)
```
    Returns the lock timeout setting.
    
    Parameters:
    
    unit - the TimeUnit of the returned value. May not be null. A value of 0 means no timeout is set.
  - getLockTimeout
```
public long getLockTimeout()
```
    Deprecated. as of 4.0, replaced by getLockTimeout(TimeUnit).
    Returns the lock timeout setting, in microseconds. This method is equivalent to:
```
getLockTimeout(TimeUnit.MICROSECONDS);
```
  - setReadOnly
```
public EnvironmentConfig setReadOnly(boolean readOnly)
```
    Convenience method for setting ENV_READ_ONLY.
    
    Parameters:
    
    readOnly - If true, configure the database environment to be read only, and any attempt to modify a database will fail.
    
    Returns:
    
    this
  - getReadOnly
```
public boolean getReadOnly()
```
    Returns true if the database environment is configured to be read only.
    This method may be called at any time during the life of the application.
    
    Returns:
    
    true if the database environment is configured to be read only.
  - setTransactional
```
public EnvironmentConfig setTransactional(boolean transactional)
```
    Convenience method for setting ENV_IS_TRANSACTIONAL.
    
    Parameters:
    
    transactional - If true, configure the database environment for transactions.
    
    Returns:
    
    this
  - getTransactional
```
public boolean getTransactional()
```
    Returns true if the database environment is configured for transactions.
    This method may be called at any time during the life of the application.
    
    Returns:
    
    true if the database environment is configured for transactions.
  - setLocking
```
public EnvironmentConfig setLocking(boolean locking)
```
    Convenience method for setting ENV_IS_LOCKING.
    
    Parameters:
    
    locking - If false, configure the database environment for no locking. The default is true.
    
    Returns:
    
    this
  - getLocking
```
public boolean getLocking()
```
    Returns true if the database environment is configured for locking.
    This method may be called at any time during the life of the application.
    
    Returns:
    
    true if the database environment is configured for locking.
  - setTxnTimeout
```
public EnvironmentConfig setTxnTimeout(long timeout,
                                       java.util.concurrent.TimeUnit unit)
                                throws java.lang.IllegalArgumentException
```
    A convenience method for setting TXN_TIMEOUT.
    
    Parameters:
    
    timeout - The transaction timeout. A value of 0 turns off transaction timeouts.
    
    unit - the TimeUnit of the timeout value. May be null only if timeout is zero.
    
    Returns:
    
    this
    
    Throws:
    
    java.lang.IllegalArgumentException - If the value of timeout is negative
    
    See Also:
    
    TXN_TIMEOUT, Transaction.setTxnTimeout(long, java.util.concurrent.TimeUnit)
  - setTxnTimeout
```
public EnvironmentConfig setTxnTimeout(long timeout)
                                throws java.lang.IllegalArgumentException
```
    Deprecated. as of 4.0, replaced by setTxnTimeout(long, TimeUnit).
    Configures the transaction timeout, in microseconds. This method is equivalent to:
```
setTxnTimeout(long, TimeUnit.MICROSECONDS);
```
    Throws:
    
    java.lang.IllegalArgumentException
  - getTxnTimeout
```
public long getTxnTimeout(java.util.concurrent.TimeUnit unit)
```
    A convenience method for getting TXN_TIMEOUT.
    A value of 0 means transaction timeouts are not configured.
    
    Parameters:
    
    unit - the TimeUnit of the returned value. May not be null.
    
    Returns:
    
    The transaction timeout.
  - getTxnTimeout
```
public long getTxnTimeout()
```
    Deprecated. as of 4.0, replaced by getTxnTimeout(TimeUnit).
    Returns the transaction timeout, in microseconds. This method is equivalent to:
```
getTxnTimeout(TimeUnit.MICROSECONDS);
```
  - setTxnSerializableIsolation
```
public EnvironmentConfig setTxnSerializableIsolation(boolean txnSerializableIsolation)
```
    A convenience method for setting TXN_SERIALIZABLE_ISOLATION.
    
    Returns:
    
    this
    
    See Also:
    
    LockMode
  - getTxnSerializableIsolation
```
public boolean getTxnSerializableIsolation()
```
    A convenience method for getting TXN_SERIALIZABLE_ISOLATION.
    
    Returns:
    
    true if the environment has been configured to have repeatable read isolation.
    
    See Also:
    
    LockMode
  - setSharedCache
```
public EnvironmentConfig setSharedCache(boolean sharedCache)
```
    A convenience method for setting the SHARED_CACHE parameter.
    
    Parameters:
    
    sharedCache - If true, the shared cache is used by this environment.
    
    Returns:
    
    this
  - getSharedCache
```
public boolean getSharedCache()
```
    A convenience method for getting the SHARED_CACHE parameter.
    
    Returns:
    
    true if the shared cache is used by this environment. @see #setSharedCache
  - setNodeName
```
public EnvironmentConfig setNodeName(java.lang.String nodeName)
```
    Sets the user defined nodeName for the Environment. If set, exception messages, logging messages, and thread names will have this nodeName included in them. If a user has multiple Environments in a single JVM, setting this to a string unique to each Environment may make it easier to diagnose certain exception conditions as well as thread dumps.
    
    Returns:
    
    this
  - getNodeName
```
public java.lang.String getNodeName()
```
    Returns the user defined nodeName for the Environment.
  - setCustomStats
```
public EnvironmentConfig setCustomStats(CustomStats customStats)
```
    Sets the custom statistics object.
    
    Returns:
    
    this
  - getCustomStats
```
public CustomStats getCustomStats()
```
    Gets the custom statstics object.
    
    Returns:
    
    customStats
  - setLoggingHandler
```
public EnvironmentConfig setLoggingHandler(java.util.logging.Handler handler)
```
    Set a java.util.logging.Handler which will be used by all java.util.logging.Loggers instantiated by this Environment. This lets the application specify a handler which
    - requires a constructor with arguments
    - is specific to this environment, which is important if the application is using multiple environments within the same process.
    Note that Handler is not serializable, and the logging handler should be set within the same process.
  - getLoggingHandler
```
public java.util.logging.Handler getLoggingHandler()
```
    Returns the custom java.util.logging.Handler specified by the application.
  - setConfigParam
```
public EnvironmentConfig setConfigParam(java.lang.String paramName,
                                        java.lang.String value)
                                 throws java.lang.IllegalArgumentException
```
    Description copied from class: EnvironmentMutableConfig
    
    Set this configuration parameter. First validate the value specified for the configuration parameter; if it is valid, the value is set in the configuration.
    
    Overrides:
    
    setConfigParam in class EnvironmentMutableConfig
    
    Parameters:
    
    paramName - the configuration parameter name, one of the String constants in this class
    
    value - The configuration value
    
    Returns:
    
    this
    
    Throws:
    
    java.lang.IllegalArgumentException - if the paramName or value is invalid.
  - setRecoveryProgressListener
```
public EnvironmentConfig setRecoveryProgressListener(ProgressListener<RecoveryProgress> progressListener)
```
    Configure the environment to make periodic calls to a ProgressListener to provide feedback on environment startup (recovery). The ProgressListener.progress() method is called at different stages of the recovery process. See RecoveryProgress for information about those stages.
    When using progress listeners, review the information at ProgressListener.progress(T, long, long) to avoid any unintended disruption to environment startup.
    
    Parameters:
    
    progressListener - The ProgressListener to callback during environment startup (recovery).
  - getRecoveryProgressListener
```
public ProgressListener<RecoveryProgress> getRecoveryProgressListener()
```
    Return the ProgressListener to be used at this environment startup.
  - setClassLoader
```
public EnvironmentConfig setClassLoader(java.lang.ClassLoader classLoader)
```
    Configure the environment to use a specified ClassLoader for loading user-supplied classes by name.
  - getClassLoader
```
public java.lang.ClassLoader getClassLoader()
```
    Returns the ClassLoader for loading user-supplied classes by name, or null if no specified ClassLoader is configured.
  - clone
```
public EnvironmentConfig clone()
```
    Returns a copy of this configuration object.
  - toString
```
public java.lang.String toString()
```
    Display configuration values.
    
    Overrides:
    
    toString in class EnvironmentMutableConfig

Name	Type	Mutable	Default	Minimum	Maximum
"je.maxMemory"	Long	Yes	0	-none-	-none-

Class EnvironmentConfig

Getting the Current Environment Properties

Time Duration Properties

Field Summary

Constructor Summary

Method Summary

Methods inherited from class com.sleepycat.je.EnvironmentMutableConfig

Methods inherited from class java.lang.Object

Field Detail

MAX_MEMORY

MAX_MEMORY_PERCENT

MAX_OFF_HEAP_MEMORY

SHARED_CACHE

MAX_DISK

FREE_DISK

ENV_RECOVERY_FORCE_CHECKPOINT

ENV_RECOVERY_FORCE_NEW_FILE

HALT_ON_COMMIT_AFTER_CHECKSUMEXCEPTION

ENV_RUN_IN_COMPRESSOR

ENV_RUN_CHECKPOINTER

ENV_RUN_CLEANER

ENV_RUN_EVICTOR

ENV_RUN_OFFHEAP_EVICTOR

ENV_BACKGROUND_READ_LIMIT

ENV_BACKGROUND_WRITE_LIMIT

ENV_BACKGROUND_SLEEP_INTERVAL

ENV_CHECK_LEAKS

ENV_FORCED_YIELD

ENV_IS_TRANSACTIONAL

ENV_IS_LOCKING

ENV_READ_ONLY

ENV_FAIR_LATCHES

ENV_LATCH_TIMEOUT

ENV_TTL_CLOCK_TOLERANCE

ENV_EXPIRATION_ENABLED

ENV_DB_EVICTION

ENV_DUP_CONVERT_PRELOAD_ALL

ADLER32_CHUNK_SIZE

LOG_TOTAL_BUFFER_BYTES

LOG_NUM_BUFFERS

LOG_BUFFER_SIZE

LOG_FAULT_READ_SIZE

LOG_ITERATOR_READ_SIZE

LOG_ITERATOR_MAX_SIZE

LOG_FILE_MAX

LOG_N_DATA_DIRECTORIES

LOG_CHECKSUM_READ

LOG_VERIFY_CHECKSUMS

LOG_MEM_ONLY

LOG_FILE_CACHE_SIZE

LOG_DETECT_FILE_DELETE

LOG_DETECT_FILE_DELETE_INTERVAL

LOG_FSYNC_TIMEOUT

LOG_FSYNC_TIME_LIMIT

LOG_GROUP_COMMIT_INTERVAL

LOG_GROUP_COMMIT_THRESHOLD

LOG_FLUSH_SYNC_INTERVAL

LOG_FLUSH_NO_SYNC_INTERVAL

LOG_USE_ODSYNC

LOG_USE_NIO

LOG_USE_WRITE_QUEUE

LOG_WRITE_QUEUE_SIZE

LOG_DIRECT_NIO

LOG_CHUNKED_NIO

ENV_RUN_VERIFIER

VERIFY_SCHEDULE

VERIFY_LOG

VERIFY_LOG_READ_DELAY

VERIFY_BTREE

VERIFY_SECONDARIES

VERIFY_DATA_RECORDS

VERIFY_BTREE_BATCH_SIZE

VERIFY_BTREE_BATCH_DELAY

NODE_MAX_ENTRIES

NODE_DUP_TREE_MAX_ENTRIES

TREE_MAX_EMBEDDED_LN

TREE_MAX_DELTA

TREE_BIN_DELTA

TREE_MIN_MEMORY

TREE_COMPACT_MAX_KEY_LENGTH