If true, database operations for which no explicit transaction handle was specified, and which modify databases in the database environment, will be automatically enclosed within a transaction.

The size of the shared memory buffer pool -- that is, the cache.

If true, Berkeley DB Concurrent Data Store applications will perform locking on an environment-wide basis rather than on a per-database basis.

If true, Berkeley DB subsystems will create any underlying files, as necessary.

The array of directories where database files are stored.

The deadlock detector configuration, specifying what lock request(s) should be rejected. As transactions acquire locks on behalf of a single locker ID, rejecting a lock request associated with a transaction normally requires the transaction be aborted.

The algorithm used by the Berkeley DB library to perform encryption and decryption.

The mechanism for reporting detailed error messages to the application.

The prefix string that appears before error messages issued by Berkeley DB.

A delegate which is called to notify the process of specific Berkeley DB events.

Monitor progress within long running operations.

If true, flush database writes to the backing disk before returning from the write system call, rather than flushing database writes explicitly in a separate system call, as necessary.

If true, the object is free-threaded; that is, concurrently usable by multiple threads in the address space.

The database environment home directory.

Whether there is any hot backup in progress.

The number of locks allocated when the environment is created

The number of lockers allocated when the environment is created

The number of lock objects allocated when the environment is created

The number of log identifier objects allocated when the environment is created

The initial number of mutexes allocated

If true, Berkeley DB will page-fault shared regions into memory when initially creating or joining a Berkeley DB environment.

The number of thread objects allocated when the environment is created

The number of transaction objects allocated when the environment is created

The intermediate directory permissions.

The current lock conflicts array.

If true, lock shared Berkeley DB environment files and memory-mapped databases into memory.

The number of lock table partitions used in the Berkeley DB environment.

The size of the lock table in the Berkeley DB environment.

A value, in microseconds, representing lock timeouts.

If true, Berkeley DB will automatically remove log files that are no longer needed.

The size of the in-memory log buffer, in bytes

The path of a directory to be used as the location of logging files. Log files created by the Log Manager subsystem will be created in this directory.

The absolute file mode for created log files. This property is only useful for the rare Berkeley DB application that does not control its umask value.

If true, Berkeley DB will flush log writes to the backing disk before returning from the write system call, rather than flushing log writes explicitly in a separate system call, as necessary.

If true, transaction logs are maintained in memory rather than on disk. This means that transactions exhibit the ACI (atomicity, consistency, and isolation) properties, but not D (durability).

If true, system buffering is turned off for Berkeley DB log files to avoid double caching.

The size of the underlying logging area of the Berkeley DB environment, in bytes.

If true, all pages of a log file are zeroed when that log file is created.

The maximum cache size

The maximum number of locking entities supported by the Berkeley DB environment.

The maximum number of locks supported by the Berkeley DB environment.

The maximum size of a single file in the log, in bytes. Because LSN Offsets are unsigned four-byte values, the size may not be larger than the maximum unsigned four-byte value.

The total number of mutexes allocated

The maximum number of locked objects

The number of file descriptors the library will open concurrently when flushing dirty pages from the cache.

The number of sequential write operations scheduled by the library when flushing dirty pages from the cache.

The number of active transactions supported by the environment. This value bounds the size of the memory allocated for transactions. Child transactions are counted as active until they either commit or abort.

The maximum file size, in bytes, for a file to be mapped into the process address space. If no value is specified, it defaults to 10MB.

The mutex alignment, in bytes.

The number of additional mutexes allocated.

If true, turn off system buffering of Berkeley DB database files to avoid double caching.

If true, Berkeley DB will grant all requested mutual exclusion mutexes and database locks without regard for their actual availability. This functionality should never be used for purposes other than debugging.

If true, Berkeley DB will copy read-only database files into the local cache instead of potentially mapping them into process memory.

If true, Berkeley DB will ignore any panic state in the database environment. (Database environments in a panic state normally refuse all attempts to call Berkeley DB functions, throwing RunRecoveryException.) This functionality should never be used for purposes other than debugging.

The number of times that test-and-set mutexes should spin without blocking. The value defaults to 1 on uniprocessor systems and to 50 times the number of processors on multiprocessor systems.

If true, overwrite files stored in encrypted formats before deleting them.

If true, allocate region memory from the heap instead of from memory backed by the filesystem or system shared memory.

The bytes component of the byte-count limit on the amount of memory to be used by shared structures in the main environment region. These are the structures other than mutexes and the page cache (memory pool).

The gigabytes component of the byte-count limit on the amount of memory to be used by shared structures in the main environment region. These are the structures other than mutexes and the page cache (memory pool).

If true, Berkeley DB will have checked to see if recovery needed to be performed before opening the database environment.

The amount of time the replication manager's transport function waits to collect enough acknowledgments from replication group clients, before giving up and returning a failure indication. The default wait time is 1 second.

If true, the replication master will automatically re-initialize outdated clients (defaults to true).

If true, the replication master sends groups of records to the clients in a single network transfer

The amount of time a master site will delay between completing a checkpoint and writing a checkpoint record into the log.

The value, relative to RepClockskewSlow, of the fastest clock in the group of sites.

The value of the slowest clock in the group of sites.

The amount of time the replication manager will wait before trying to re-establish a connection to another site after a communication failure. The default wait time is 30 seconds.

If true, the client should delay synchronizing to a newly declared master (defaults to false). Clients configured in this way will remain unsynchronized until the application calls RepSync()()().

Configure the amount of time the replication manager will wait before retrying a failed election. The default wait time is 10 seconds.

The timeout period for an election. The default timeout is 2 seconds.

An optional configuration timeout period to wait for full election participation the first time the replication group finds a master. By default this option is turned off and normal election timeouts are used. (See the Elections section in the Berkeley DB Reference Guide for more information.)

The amount of time the replication manager, running at a client site, waits for some message activity on the connection from the master (heartbeats or other messages) before concluding that the connection has been lost. When 0 (the default), no monitoring is performed.

The frequency at which the replication manager, running at a master site, broadcasts a heartbeat message in an otherwise idle system. When 0 (the default), no heartbeat messages will be sent.

The amount of time a client grants its master lease to a master. When using master leases all sites in a replication group must use the same lease timeout value. There is no default value. If leases are desired, this method must be called prior to calling RepStartClient()()() or RepStartMaster()()().

Set the message dispatch function. It is responsible for receiving messages sent from remote sites using either SendMessage(array<DatabaseEntry>[]()[]) or SendRequest(array<DatabaseEntry>[]()[], UInt32). If the message received by this function was sent using SendMessage(array<DatabaseEntry>[]()[]), then no response is required. If the message was sent using SendRequest(array<DatabaseEntry>[]()[], UInt32), then this function must send a response using SendMessage(array<DatabaseEntry>[]()[]).

Specify how master and client sites will handle acknowledgment of replication messages which are necessary for "permanent" records. The current implementation requires all sites in a replication group configure the same acknowledgement policy.

The local site of the replication manager. Returns null if the local site has not been configured.

The status of the sites currently known by the replication manager.

If true, Replication Manager automatically runs elections to choose a new master when the old master appears to have become disconnected (defaults to true).

If true, Berkeley DB method calls that would normally block while clients are in recovery will return errors immediately (defaults to false).

The total number of sites in the replication group.

The database environment's priority in replication group elections. A special value of 0 indicates that this environment cannot be a replication group master. If not configured, then a default value of 100 is used.

The maximum number of microseconds a client waits before requesting retransmission.

The minimum number of microseconds a client waits before requesting retransmission.

Replication Manager observes the strict "majority" rule in managing elections, even in a group with only 2 sites. This means the client in a 2-site group will be unable to take over as master if the original master fails or becomes disconnected. (See the Elections section in the Berkeley DB Reference Guide for more information.) Both sites in the replication group should have the same value for this parameter.

The bytes component of the byte-count limit on the amount of data that will be transmitted from a site in response to a single message processed by RepProcessMessage(DatabaseEntry, DatabaseEntry, Int32).

The gigabytes component of the byte-count limit on the amount of data that will be transmitted from a site in response to a single message processed by RepProcessMessage(DatabaseEntry, DatabaseEntry, Int32).

The delegate used to transmit data using the replication application's communication infrastructure.

If true, master leases will be used for this site (defaults to false).

If true, catastrophic recovery was run on this environment before opening it for normal use.

If true, normal recovery was run on this environment before opening it for normal use.

The number of microseconds the thread of control will pause before scheduling further write operations.

A delegate that returns a unique identifier pair for the current thread of control.

A delegate that formats a process ID and thread ID identifier pair.

If true, allocate region memory from system shared memory instead of from heap memory or memory backed by the filesystem.

The path of a directory to be used as the location of temporary files.

An approximate number of threads in the database environment.

A delegate that returns if a thread of control (either a true thread or a process) is still running.

If true, database calls timing out based on lock or transaction timeout values will throw LockNotGrantedException instead of DeadlockException.

If true, Berkeley DB will not write or synchronously flush the log on transaction commit.

If true and a lock is unavailable for any Berkeley DB operation performed in the context of a transaction, cause the operation to throw DeadlockException (or LockNotGrantedException if configured with TimeNotGranted).

If true, all transactions in the environment will be started as if Snapshot was passed to BeginTransaction()()(), and all non-transactional cursors will be opened as if SnapshotIsolation was passed to Cursor()()().

A value, in microseconds, representing transaction timeouts.

The recovery timestamp

If true, Berkeley DB will write, but will not synchronously flush, the log on transaction commit.

The Berkeley DB process' environment may be permitted to specify information to be used when naming files; see Berkeley DB File Naming in the Programmer's Reference Guide for more information.

If true, all databases in the environment will be opened as if UseMVCC was set.

If true, locking for the Berkeley DB Concurrent Data Store product was initialized.

If true, the locking subsystem was initialized.

If true, the logging subsystem was initialized.

If true, the shared memory buffer pool subsystem was initialized.

If true, the replication subsystem was initialized.

If true, the transaction subsystem was initialized.

Specific additional informational and debugging messages in the Berkeley DB message output.

If true, Berkeley DB will yield the processor immediately after each page or mutex acquisition.