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
