On Tue, 2006-01-10 at 14:34 +0800, Paolo Alexis Falcone wrote: > Quoting [EMAIL PROTECTED]: > > > > > i'm using bdb sir. > > Normally OpenLDAP's bdb backend won't exhibit such weirdness as it's touted to > be transaction-safe (as opposed to the old ldbm - fast but not safe). A side > effect would be that a bdb backend would impose higher I/O. Have you absolved > hardware problems as probable causes? You've also tried checking for possible > kernel issues or BerkeleyDB issues (although it's a bit unlikely unless you > roll your own versions, unsupported by vendors at most, of those software). >
As for transaction-safeness of BerkeleyDB, the lack of cross-process locking mechanisms for the file backend makes BerkeleyDB a not-so-good choice for mission-critical application development AFAIK. I've experienced this first hand, and I can tell that relying on BerkeleyDB to do its own integrity management is a big no-no. However, you may argue that the writers of OpenLDAP would've done good by implementing their own locking on the database backend -- which actually defeats the purpose of BerkeleyDB being transaction-safe. I've experienced one too many a times wherein file-backed BerkeleyDB databases have conked out on me because precisely of the lack of cross-process locking mechanisms. This is using BerkeleyDB 4.3 and the libdb_cxx library for C++ bindings -- and using libdb in itself doesn't help. So in this case, I'm not surprised if BerkeleyDB conked out on any application. I've been burned before, and now I'm, moving away from BerkeleyDB -- far far away. My $0.02 worth. -- Dean Michael C. Berris Mobile +639287291459 URL http://mikhailberis.blogspot.com YMID: mikhailberis _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
