This content has been marked as final. Show 4 replies
if you ask for a recovery upon open, then recovery will ALWAYS take place no matter what. BDB is an embedded library and as such takes directions from the embedding application what to do. It takes time to perform recovery, and rebuild the environment files. It is always safest to assume recovery is needed when opening a database. If the database was shut down cleanly, then there would not be any uncommitted txns. It is your choice whether or not you specify to perform recovery on the open.
I discovered the problem. When you set Recover to true on environment open, whilst stepping through with the Visual Studio debugger, it takes almost two minutes to open the environment, whether or not you have uncommitted transactions. I just tried the exact code on the same enviroment by running without the debugger and in this case the enviroment opens instantly.
This is strange behaviour, which is most likely related to the BDB .net API (I'm guessing)
For now , I'll leave the question as unanswered.
Figured out the problem.
In the environment config, I had set Verbose to send all messages. Its best to just leave verbose null. It seems to send its output to stdout, which in the case of my debugger goes to the output window, and is monumentally slow.
Its a silly oversight, but I answer here in case anyone has a similar issue.
thanks for taking the time to post the solution, we appreciate it - as it helps everyone. So many times these types of problems are not obvious and are not code related. Yes, sending output to a debugger can be very time consuming.