Re: Automatically managing inactiveDestroy property.
- From: Tim.Bunce@xxxxxxxxx (Tim Bunce)
- Date: Tue, 25 Mar 2008 10:40:57 +0000
Sounds like you could just set InactiveDestroy on all handles by
default, but then turn it off in the parent process just before it
disconnects/exits.
You could also possibly play games overriding CORE::GLOBAL::fork()
and CORE::GLOBAL::system().
Tim.
On Mon, Mar 24, 2008 at 12:04:48PM -0400, Lenga, Yair wrote:
Hi,.
I have a complex CGI program, which need to call external program, while
keeping the DBI connection open. I'm struggling with the
"InactiveDestroy" property. Per the DBI perldoc:
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" on all
their
shared handles. Note that some databases, including Oracle,
don't
support passing a database connection across a fork.
My problem is that I do not have any control over the interface to the
external program (3rd party perl code that I can not modify), which is
using both 'fork' and 'system'. In the past, I solved the problem using
the following method:
- Before calling the 3rd party library, the code will fork.
- The child will mark the inactiveDestroy.
- Code will call the 3rd party library
- Parent wait for child to complete.
This logic worked OK until I got extra requirements to store the results
of the 3rd party calls in the DB. Initially, I tried to push the results
from the child to the parent (using a pipe), but this is getting more
complex - as I requirement expanded to pass more data between the 3rd
party calls and the DB.
My questions/suggestion:
Will it make sense to manage the 'inactiveDestroy' automatically using
one of the following policies:
(A) Remember in the DBI handle the PID of the calling process, and
assume the 'InactiveDestroy' was turned on when the handle goes out of
scope on a process with a different PID (e.g, children). For me, this
solution will provide a clean handling of all the cases.
(B) Add a new property 'AutoInactiveDestroy' which will do the same. The
code will have to turn this property on (when the connection is created,
or before the fork).
I can not think of any situation where (A) will not work - but my
experience is limited to Linux/SunOS with Sybase/SQLITE/SQLServer.
Any feedback will be appreciated.
Regards,
Yair Lenga
- Prev by Date: Re: Statement handle still Active: prepare_cached
- Next by Date: Re: Cwd failing on PA-RISC2.0-thread-multi-LP64 (was: New DBI-1.604)
- Previous by thread: Cwd failing on PA-RISC2.0-thread-multi-LP64 (was: New DBI-1.604)
- Next by thread: DBI 1.604 builds clean on Solaris 10 against 64 bit Perl 5.8.8
- Index(es):
Relevant Pages
|
|
