Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: Michael Peppler <mpeppler at peppler dot org>
Subject: Re: Automatically managing inactiveDestroy property.
Date: Apr 22 2008 4:54PM

I haven't forgotten... I'll try to get something in the next couple of 


Lenga, Yair wrote:
> Hi,
> Just following up if you had a chance to review this request ...
> Thanks
> Yair 
> -----Original Message-----
> From: []
> On Behalf Of
> Sent: Thursday, April 10, 2008 9:18 AM
> To:
> Subject: Re: Automatically managing inactiveDestroy property.
> Quick response (I'll respond more completely from home tonight):
> DBD::Sybase should support accessing the db handle from both the parent
> and the child as that's supported by OpenClient (although I haven't
> tried it with DBD::Sybase - I *have* done it with Sybase::CTlib).
> Anyway - the PID idea seems reasonable at first glance, but I need to
> think about it a bit  to see if there might be any downsides...
> Michael
> "Lenga, Yair " 
> Sent by:
> 10.04.2008 14:38
> To
> cc
> Subject
> Automatically managing inactiveDestroy property.
> Greetings,
> I've posted the following questions to dbi-dev.
> The short version is that I was hoping to have a way to manage the
> "inactiveDestory" property on DBI drivers which can not work across fork
> (e.g., DBD::Sybase). I've got a suggestion from Tim Bunce, which will
> solve most of the cases - but require modifying third-party source code.
> I'm hoping for a solution that does not require any source code changes
> to third-party code.
> My question/request: Will it make sense to add an option to the
> DBD::Sybase as follows ?
> = DBD::Sybase will remember the current PID when the object get created.
> = If the DBD::Sybase object goes out of scope, it will not "DISCONNECT",
> unless the current PID is the same as the saved PID.
> = It should be possible to activate this features "externally"
> (parameter on the connection string, env var, etc), even when the DBI
> handle is not accessible.
> As a side comment, I think it make sense to make this the default
> behavior. I've been working with DBD::Sybase since version 0.13
> (~1999?), and I can not recall a case where I wanted the Sybase
> connection on the child process. I had many instances were I exteneded
> existing programs using DBD::Sybase, which broke the DB connection,
> because I forgot to explicitly manage the "inactiveDestory" property.
> The rational for this change is that (in most situations), we do not
> want to destroy the DBD::Sybase object in the child (after the fork).
> Having to manually capture the fork, and manage the inactiveDestory is
> very hard when using third party modules. As per feedback from dbi-dev,
> the feature does not fit into DBI, because there are some drivers which
> can work across fork calls (e.g., DBD::SQLite, and similar). 
> Thanks for taking the time to review this posting. Any feedback is
> welcomed.
> Yair
> Original Posting to dbi-dev, and Tim's response listed below.
> 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
> Tim Bunce suggested:
>> 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.
> -----------------------------------------
> This communication is for informational purposes only. It is not
> intended as an offer or solicitation for the purchase or sale of any
> financial instrument or as an official confirmation of any transaction.
> All market prices, data and other information are not warranted as to
> completeness or accuracy and are subject to change without notice. Any
> comments or statements made herein do not necessarily reflect those of
> JPMorgan Chase & Co., its subsidiaries and affiliates.
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure under
> applicable law. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution, or use of the
> information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED. Although this transmission and any
> attachments are believed to be free of any virus or other defect that
> might affect any computer system into which it is received and opened,
> it is the responsibility of the recipient to ensure that it is virus
> free and no responsibility is accepted by JPMorgan Chase & Co., its
> subsidiaries and affiliates, as applicable, for any loss or damage
> arising in any way from its use. If you received this transmission in
> error, please immediately contact the sender and destroy the material in
> its entirety, whether in electronic or hard copy format. Thank you.
> Please refer to for
> disclosures relating to UK legal entities.

Michael Peppler           -                 Peppler Consulting SaRL      -        
Sybase DBA/Developer      -   TeamSybase:
Sybase on Linux FAQ       -