On 5/9/07, Tom Allison <[EMAIL PROTECTED]> wrote:
> sing its handle unexpectedly.
>
> The solution:
>
> Setting a flag (InactiveDestroy) on the parent's handle inside the
> child process prevents the automagic closing of the connection.
>
> * the magic in this case is the DESTROY method of DBI::db
Where do you get the inactiveDestroy?
Is this something missed in the RTFM?
from perldoc DBI (version 1.53, I don't know when it debuted)
"InactiveDestroy" (boolean)
The default value, false, means a handle will be fully destroyed as
normal when the last reference to it is removed, just as you'd
expect.
If set true then the handle will be treated by the DESTROY as if it
was no longer Active, and so the database engine related effects of
DESTROYing a handle will be skipped.
Think of the name as meaning 'treat the handle as not-Active in the
DESTROY method'.
For a database handle, this attribute does not disable an explicit
call to the disconnect method, only the implicit call from DESTROY
that happens if the handle is still marked as "Active".
This attribute is specifically designed for use in Unix applica‐
tions that "fork" child processes. Either the parent or the child
process, but not both, should set "InactiveDestroy" true on all
their shared handles. (Note that some databases, including Oracle,
don't support passing a database connection across a fork.)
To help tracing applications using fork the process id is shown in
the trace log whenever a DBI or handle trace() method is called.
The process id also shown for every method call if the DBI trace
level (not handle trace level) is set high enough to show the trace
from the DBI's method dispatcher, e.g. >= 9.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
