sybperl-l Archive

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 
weeks.

Michael

Lenga, Yair wrote:
> Hi,
> 
> Just following up if you had a chance to review this request ...
> 
> Thanks
> Yair 
> 
> -----Original Message-----
> From: owner-sybperl-l@peppler.org [mailto:owner-sybperl-l@peppler.org]
> On Behalf Of michael.x.peppler@jpmchase.com
> Sent: Thursday, April 10, 2008 9:18 AM
> To: sybperl-l@peppler.org
> 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: owner-sybperl-l@peppler.org
> 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 http://www.jpmorgan.com/pages/disclosures for
> disclosures relating to UK legal entities.
> 
> 
> 
> 


-- 
Michael Peppler           -                 Peppler Consulting SaRL
mpeppler@peppler.org      -                  http://www.peppler.org
Sybase DBA/Developer      -   TeamSybase: http://www.teamsybase.com
Sybase on Linux FAQ       -   http://www.peppler.org/FAQ/linux.html