On 7/19/07, Nils Kaiser <[EMAIL PROTECTED]> wrote:
I was able to change our code to have the handlers called by the Apache
server (PerlResponseHandler, PerlChildInitHandler,
PerlChildExitHandler). What I don't understand, is in which scope/object
I store the reference to the BerkeleyDB in the ini
Hello,
I was able to change our code to have the handlers called by the Apache
server (PerlResponseHandler, PerlChildInitHandler,
PerlChildExitHandler). What I don't understand, is in which scope/object
I store the reference to the BerkeleyDB in the init handler? And of
course, how I access t
On Jul 13, 2007, at 9:48 AM, Perrin Harkins wrote:
On 7/13/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
I'm thinking of the situation where you have 1 parent, 4 children.
all 4 children hit max-requests and exit before the first replacement
spawns. without a standing connection in the pare
On 7/13/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
I'm thinking of the situation where you have 1 parent, 4 children.
all 4 children hit max-requests and exit before the first replacement
spawns. without a standing connection in the parent (or another
process using bdb in any way ) wouldn't
First off- thank you perrin , i'm a step closer to fully
understanding this.
On Jul 12, 2007, at 9:14 PM, Perrin Harkins wrote:
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
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
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
?
m
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
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 o
