berkeleyDB tie once and forever with mod_perl
Hello, in a former post, I was investigating the use of berkeleyDB and mod_perl to cache calls to a web service. We now have a running prototype. To achieve full performance, I read that it better to tie the berkeleyDB once and reuse the handle for each request, i.e. having the tie command outside of the mod_perl handler. Has someone example code to do that? I can imagine how to tie on startup, but how to trigger the code for untie at shutdown? Is untie needed at all with berkeleyDB? We are using berkeleyDB 4 with the berkeleyDB module from CPAN, mod_perl 2.0 and apache 2.0 on linux. Thx in advance, Nils
Re: berkeleyDB tie once and forever with mod_perl
On 7/12/07, Nils Kaiser <[EMAIL PROTECTED]> wrote: To achieve full performance, I read that it better to tie the berkeleyDB once and reuse the handle for each request, i.e. having the tie command outside of the mod_perl handler. Yes. If you really are concerned with performance, don't use the tie API at all. Use the OO methods (get, put) directly. Has someone example code to do that? If this is read/write, you need to use the BerkeleyDB::Env stuff. If you google a little you should find some examples. I know I've put a few here and on perlmonks.org. I can imagine how to tie on startup, but how to trigger the code for untie at shutdown? Is untie needed at all with berkeleyDB? Yes, do the untie to flush buffers to disk. The appropriate place to do this is the PerlChildInitHandler and PerlChildExitHandler. Do not try to open it in the parent process. - Perrin
Re: berkeleyDB tie once and forever with mod_perl
Could you elaborate on this? I'm a bit unclear: are you suggesting 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 ? 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 said, it seems that in order to keep the shared memory around, you'd need to start some connection pre-fork. the child-init stuff suggests that there are multiple post-fork connections though. so i'm a bit lost. thanks
[mp2] apache2::build missing from fedora 7 mod_perl?
all - i've just set up a new fedora 7 installation on my laptop. when trying to build an rpm for libapreq2, it dies telling me that apache::test.pm is not found. after retrieving apache::test from cpan and trying to build an rpm for that, it tells me that apache2::build is not found. cpan tells me that apache2::build is part of the mod_perl-2.0.3 package, which is installed on my fedora 7 system. however, there seems to be no apache/build.pm module anywhere in /usr/lib/perl5. am i missing something here? regards, paul
Re: [mp2] apache2::build missing from fedora 7 mod_perl?
paul trader wrote: > however, there seems to be no apache/build.pm module anywhere in > /usr/lib/perl5. > > am i missing something here? I normally build my own Perl/mod_perl on my systems since RH ships a threaded Perl which I never need and which is slower than a Perl built with just the defaults. But this does look like a bug on RH's part, so I'd report it to: [EMAIL PROTECTED] -- Michael Peters Developer Plus Three, LP
Re: berkeleyDB tie once and forever with mod_perl
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
