Berkeley DB, was Telecom & Mnesia - Call Detail Record Collection

[Scott Lystig Fritchie]

>>>>> "cw" == Klacke  <klacke@REDACTED> writes:

cw> I looked a lot at the berkeley db a couple of years ago, the one
cw> thing that made me stop workin on it was that I was never able to
cw> figure out how to repair a broken berkely db file. Writing into
cw> the berkely db updates the metadata for the file in way where
cw> there are certain points in time where the file is
cw> broken.... That's at least how I recall it.

A friend of mine, I'll call him Bob, is much more familiar with the
beauty and perils of Berkeley DB.  He says:

bob> There are known problems with recovery in DB 3.0.55 where it gets
bob> confused trying to redo the log.  They rewrote the recovery subsystem
bob> in 3.1 and things appear to be much better since then.

I also asked:

>The only other related thing I can dredge from memory is that it
>was/is? easier to hose a DB transaction system with multiple processes
>operating in the same environment instead of a multithreaded single
>process.

bob> Oh, yes.  All process that use the environment must have closed it
bob> before recovery is performed.  That can be by killing them or politely,
bob> bearing in mind that processes may hang on a lock held by another thread
bob> that choked, so that killing it may be the only way to get it out.
bob> 
bob> If some process is still in the database when you run recovery, well,
bob> all bets are off.

On the Erlang driver front, things have been going well.  I've got my
dynamically loadable driver using Berkeley DB 4.0.14.  It's creating
tables and doing basic record storage & retrieval.  There appear to be
some memory leaks that I'll have to track down ... but adding
functionality is more fun right now.  :-) Perhaps I'll get the
cursor-related calls typed in yet tonight before the pint of
Boddington's hits me full force....

-Scott