It's the responsibility of the processes (and/or threads of control) using a Berkeley DB environment to ensure recovery is never performed if there are other processes running recovery or using an existing database environment. It would be great if Berkeley DB could solve this, but it requires a way to single-thread execution on a system, and there's rarely anything Berkeley DB can use for that purpose -- let alone a portable method.
Most application suites solve this problem by writing a tiny watch program that recovers the database environment and then runs the processes that actually use the database environment to perform work. The watcher program then monitors the working processes, and if any of them exit badly for any reason, the watcher kills any remaining processes and restarts the cycle.
In the C API, the DB and DB_ENV structures each contain an "app_private" field intended to be used to reference application-specific information. See the db_create and db_env_create documentation for more information.
In the C++ or Java APIs, the easiest way to associate application-specific data with a handle is to subclass the Db or DbEnv, for example subclassing Db to get MyDb. Objects of type MyDb will still have the Berkeley DB API methods available on them, and you can put any extra data or methods you want into the MyDb class. If you are using "callback" APIs that take Db or DbEnv arguments (for example, Db::set_bt_compare) these will always be called with the Db or DbEnv objects you create. So if you always use MyDb objects, you will be able to take the first argument to the callback function and cast it to a MyDb (in C++, cast it to (MyDb*)). That will allow you to access your data members or methods.
Copyright Sleepycat Software