Database Recovery from Failed Processes

Database recovery can be necessary in a number of situations. For example, consider a multi-process implementation: a bug in the application could cause the eXtremeDB runtime to be corrupted in process A, in turn causing mco_stop() to be called, while it has the database “locked” (i.e. is performing a READ_WRITE transaction with the MURSIW transaction manager) while one or more other processes have active connections to the database. These other processes will effectively be blocked by the “hung” process A. In this case, “recovery” would be affected by “killing” process A which removes all locks held by its database connections and closes the connections, thus freeing the other processes to proceed with their active database connections.

Because there is no system-independent way to detect when a process has failed, eXtremeDB provides the “sniffer” utility to allow C and C++ applications to detect and remove “dead” connections in their specific operating environment.

Please refer to the C API Database Recovery page for a detailed explanation.

Persistent Databases

The recovery of a persistent database in the case of a system failure is performed automatically by the eXtremeDB runtime during the open process when a log file exists.

Please use the links below to view detailed explanations and examples for your development environment:

C	Automatic persistent database recovery in C
C++	Automatic persistent database recovery in C++
Java	Automatic persistent database recovery in Java
Python	Automatic persistent database recovery in Python
C#	Automatic persistent database recovery in C#