On Wed, 22 Nov 2000, Tim Bunce wrote:
> I'm puzzled why people wouldn't just use version 3 of Berkeley DB (via
> DB_File.pm or BerkeleyDB.pm) which supports multiple readers and
> writers through a shared memory cache.  No open/close/flush required
> per-write and very very much faster.
> 
> Is there a reason I'm missing?

There are a few.  It's much harder to build than most CPAN modules, partly
because of conflicts some people run into with the db library Red Hat
provides.  The documentation is pretty weak on how to use it with a shared
memory environment.  (You have to use BerkeleyDB.pm for this incidentally;
DB_File does not support it.)  We got past these problems and then ran
into issues with db corruption.  If Apache gets shut down with a SIGKILL
(and this seems to happen fairly often when using mod_perl), the data can
be corrupted in such a way that when you next try to open it BerkeleyDB
will just hang forever.  Sleepycat says this is a known issue with using
BerkeleyDB from Apache and they don't have a solution for it yet.  Even
using their transaction mechanism does not prevent this problem.

We tried lots of different things and finally have reached what seems to
be a solution by using database-level locks rather than page-level.  We
still get to open the database in ChildInit and keep it open, with all the
speed benefits of the shared memory buffer.  It is definitely the fastest
available way to share data between processes, but the problems we had
have got me looking at other solutions again.

If you do try it out, I'd be eager to hear what your experiences with it
are.

- Perrin


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to