The database files that need to be archived in order to recover the database from catastrophic failure. If any of the database files have not been accessed during the lifetime of the current log files, they will not included in this list. It is also possible that some of the files referred to by the log have since been deleted from the system.

The names of all of the log files that are no longer in use (for example, that are no longer involved in active transactions), and that may safely be archived for catastrophic recovery and then removed from the system.

Allocate a locker ID in an environment configured for Berkeley DB Concurrent Data Store applications.

Close the Berkeley DB environment, freeing any allocated resources and closing any underlying subsystems.

Run one iteration of the deadlock detector. The deadlock detector traverses the lock table and marks one of the participating lock requesters for rejection in each deadlock it finds.

Determines whether the specified Object is equal to the current Object.

Check for threads of control (either a true thread or a process) that have exited while manipulating Berkeley DB library data structures, while holding a logical database lock, or with an unresolved transaction (that is, a transaction that was never aborted or committed).

Serves as a hash function for a particular type.

Gets the Type of the current instance.

Map an LSN object to a log filename

The names of all of the log files

Append a record to the log

Instantiate a new DatabaseEnvironment object and open the Berkeley DB environment represented by home.

Set the panic state for the database environment. (Database environments in a panic state normally refuse all attempts to call Berkeley DB functions, throwing RunRecoveryException.)

Restore transactions that were prepared, but not yet resolved at the time of the system shut down or crash, to their state prior to the shut down or crash, including any locks previously held.

The environment regions, including any backing files, are removed. Any log or database files and the environment directory are not removed.

If there are processes that have called Open(String, DatabaseEnvironmentConfig) without calling Close()()() (that is, there are processes currently using the environment), Remove will fail without further action.

Calling Remove should not be necessary for most applications because the Berkeley DB environment is cleaned up as part of normal database recovery procedures. However, applications may want to call Remove as part of application shut down to free up system resources. For example, if SystemMemory was specified to Open(String, DatabaseEnvironmentConfig), it may be useful to call Remove in order to release system shared memory segments that have been allocated. Or, on architectures in which mutexes require allocation of underlying system resources, it may be useful to call Remove in order to release those resources. Alternatively, if recovery is not required because no database state is maintained across failures, and no system resources need to be released, it is possible to clean up an environment by simply removing all the Berkeley DB files in the database environment's directories.

In multithreaded applications, only a single thread may call Remove.

Remove log files that are no longer needed. Automatic log file removal is likely to make catastrophic recovery impossible.

RepHoldElection is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

If the election is successful, Berkeley DB will notify the application of the results of the election by means of either the REP_ELECTED or REP_NEWMASTER events (see EventNotifyfor more information). The application is responsible for adjusting its relationship to the other database environments in the replication group, including directing all database updates to the newly selected master, in accordance with the results of the election.

The thread of control that calls RepHoldElection must not be the thread of control that processes incoming messages; processing the incoming messages is necessary to successfully complete an election.

Before calling this method, the RepTransport delegate must already have been configured to send replication messages.

There are two ways to build Berkeley DB replication applications: the most common approach is to use the Berkeley DB library "replication manager" support, where the Berkeley DB library manages the replication group, including network transport, all replication message processing and acknowledgment, and group elections. Applications using the replication manager support generally make the following calls:

1. Configure the local site in the replication group, RepMgrLocalSite.
2. Call RepMgrAddRemoteSite(ReplicationHostAddress) to configure the remote site(s) in the replication group.
3. Configure the message acknowledgment policy (RepMgrAckPolicy) which provides the replication group's transactional needs.
4. Configure the local site's election priority, RepPriority.
5. Call RepMgrStartClient(Int32) or RepMgrStartMaster(Int32) to start the replication application.

For more information on building replication manager applications, please see the Replication Getting Started Guide included in the Berkeley DB documentation.

Applications with special needs (for example, applications using network protocols not supported by the Berkeley DB replication manager), must perform additional configuration and call other Berkeley DB replication methods. For more information on building advanced replication applications, please see the Base Replication API section in the Berkeley DB Programmer's Reference Guide for more information.

Starting the replication manager consists of opening the TCP/IP listening socket to accept incoming connections, and starting all necessary background threads. When multiple processes share a database environment, only one process can open the listening socket; RepMgrStartClient(Int32) (and RepMgrStartMaster(Int32)) automatically open the socket in the first process to call it, and skips this step in the later calls from other processes.

Start the replication manager as a master site, and do not call for an election.

Process an incoming replication message sent by a member of the replication group to the local database environment.

Set the clock skew ratio among replication group members based on the fastest and slowest measurements among the group for use with master leases.

Set a threshold for the minimum and maximum time that a client waits before requesting retransmission of a missing message.

Set a 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 limit is not a hard limit, and the record that exceeds the limit is the last record to be sent.

Initialize the communication infrastructure for a database environment participating in a replicated application.

RepStartClient is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

Replication master environments are the only database environments where replicated databases may be modified. Replication client environments are read-only as long as they are clients. Replication client environments may be upgraded to be replication master environments in the case that the current master fails or there is no master present. If master leases are in use, this method cannot be used to appoint a master, and should only be used to configure a database environment as a master as the result of an election.

Before calling this method, the RepTransport delegate must already have been configured to send replication messages.

RepStartMaster is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

Replication master environments are the only database environments where replicated databases may be modified. Replication client environments are read-only as long as they are clients. Replication client environments may be upgraded to be replication master environments in the case that the current master fails or there is no master present. If master leases are in use, this method cannot be used to appoint a master, and should only be used to configure a database environment as a master as the result of an election.

Before calling this method, the RepTransport delegate must already have been configured to send replication messages.

Force master synchronization to begin for this client.

Allow database files to be copied, and then the copy used in the same database environment as the original.

Allow database files to be moved from one transactional database environment to another.

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

Returns a String that represents the current Object.

Ensure that a specified percent of the pages in the cache are clean, by writing dirty pages to their backing files.

WriteToLog allows applications to include information in the database environment log files, for later review using the db_printlog utility. This method is intended for debugging and performance tuning.

WriteToLog allows applications to include information in the database environment log files, for later review using the db_printlog utility. This method is intended for debugging and performance tuning.