On 7/12/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
a) the tie be global pre-fork
b) the tie be post-fork
c) there be no tie whatsoever , and somehow a connection is made
using the API at the beginning , and everything just uses the library/
api methods
~b + ~c
Open it after the fork, in the PerlChildInitHandler (or really any
time after the fork, since unlike an RDMBS connection, this open is
very fast). Use the OO API, not the tied interface. (The tied
interface works fine, but it's slower.)
my understanding of the bdb integration w/modperl, thanks to bits &
pieces from perrin over the years , is that bdb takes care of its own
locking / access & pools a bunch of shared memory
That's correct.
that said, it seems that in order to keep the shared memory around,
you'd need to start some connection pre-fork.
No. This is explicit shared memory, not a mysterious copy-on-write
thing. You need to initiate access separately from each process so
that none of the XS stuff is shared, just as you would with RDBMS
connections.
There might be some way to safely open the database in the parent
process, especially if you're doing read-only access, or it might be
smart enough to figure out the PID changed and do whatever it needs to
do. Feel free to comb the BDB docs for it. I don't think there's any
advantage to doing so though.
- Perrin
