I have a pernicious bug that completely baffles me: in order to optimize a particular piece of mod_perl code, we decided to fork off a part of the code and return the user to a status page while the child does the crunching in the background. So our code now looks something like this:
defined(my $pid = fork) or die "cannot fork. $!\n"; if ($pid){ warn "i'm the parent"; } else { &do_stuff(@args); CORE::exit(0); } return;
now, &do_stuff creates its own dbi handle (DBD::Oracle), and does a bunch of operations with that. the parent returns and the next page (the success/status page) does more operations with its own pre-declared dbi handles.
at this point what happens is that oracle throws one of numerous exceptions: "fatal two-task communication protocol error", "user requested cancel of current operation", "requested INSTANCE_NUMBER is busy", "end-of-file on communication channel", etc, etc.... there seems to be no consistency with which error you receive.
my theory is that a race condition exists between the parent and child processes, somehow fighting over control of the db handles, even though the child handle is created after the fork. How do i get around this?
The system:i've tried adding Apache::DBI->connect_on_init to no avail, as well as POSIX::setsid. can anyone help me?
In reply to forking w/ mod_perl and DBI by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |