-Original Message-
>From: Chas Owens <[EMAIL PROTECTED]>
>In his case there is not a portability issue. What is not portable is
>using the parent's handle inside the child, but he is opening a new
>handle inside the child. The problem was the auto-close behavior
>which is made a non-probl
On 5/9/07, Tom Allison <[EMAIL PROTECTED]> wrote:
snip
In short -- you are lucky it can be supported.
But in order to keep things portable, this might be something to avoid?
In his case there is not a portability issue. What is not portable is
using the parent's handle inside the child, but he
On May 9, 2007, at 5:41 PM, Jeff Pang wrote:
-Original Message-
From: Chas Owens <[EMAIL PROTECTED]>
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 DES
-Original Message-
>From: Chas Owens <[EMAIL PROTECTED]>
>$dbh->{InactiveDestroy} = 1;
>$dbh = DBI->connect($dsn, $dbun, $dbpw,
>{RaiseError => 1});
># do stuff
yes this is the same with my meanings.Child re-open an
On 5/9/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
snip
Using InactiveDestroy flag seems a standard way since this module's author
provide this flag.
But it's maybe bring some problems when the applications are large enough,and
it's not
the fact that every programmer would disconnect their dbh con
-Original Message-
>From: Chas Owens <[EMAIL PROTECTED]>
>
>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
Using InactiveDest
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::d
-Original Message-
>From: Chas Owens <[EMAIL PROTECTED]>
>
>And happily such a flag exists: InactiveDestroy.
>
>Just add
>
>$dbh->{InactiveDestroy} = 1;
>
>to the child and the problem should go away.
>
I'm also happy to know it,this is good.
--
mailto:[EMAIL PROTECTED]
http://home.arco
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 miss
On 5/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
This is an interesting point, but I think a database might be more
similar to a network socket than a file handle.
I have this same observed behaviour under Oracle and PostgreSQL, so it's
not limited to mysql (and shouldn't be fixed with my
"Jeff Pang" <[EMAIL PROTECTED]> wrote:
>
>
>-Original Message-
>>From: Chas Owens <[EMAIL PROTECTED]>
>>Sent: May 10, 2007 12:02 AM
>>To: Jeff Pang <[EMAIL PROTECTED]>
>>Cc: beginners-list
>>Subject: Re: forking
create the database connection after you fork().
On 5/9/2007, "Chas Owens" <[EMAIL PROTECTED]> wrote:
>On 5/9/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
>snip
>> This is the reason really.I was also confused for this case once.
>> Thanks for Chas's explain.
>snip
>
>Knowing what is happe
I started here and I didn't read the rest of the many posts.
I tried this too under a variety of database and I think it comes down to
this:
You can't fork and network or other type of connection and expect
reality to remain continuous.
If I create an object that has a reference to single
On 5/9/07, Chas Owens <[EMAIL PROTECTED]> wrote:
On 5/9/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
snip
> Yes but I think is this maybe a bug in DBI class?For example,open a file
handle and
> after forking child close that handle,this would not affect parent's handle.
snip
It definitely violates
On 5/9/07, Jeremy Kister <[EMAIL PROTECTED]> wrote:
On 5/9/2007 11:12 AM, Chas Owens wrote:
> my $dbh = DBI->connect($dsn, $dbun, $dbpw, {RaiseError => 1});
>
> to
>
> my $dbh = DBI->connect(
> $dsn, $dbun, $dbpw,
> {
> RaiseError => 1,
> mysql_auto_reconnect => 1
> }
-Original Message-
>From: Jeremy Kister <[EMAIL PROTECTED]>
>Sent: May 10, 2007 12:17 AM
>To: beginners@perl.org
>Subject: Re: forking problem with dbd::mysql
>
>On 5/9/2007 11:12 AM, Chas Owens wrote:
>> my $dbh = DBI->connect($dsn, $dbun, $dbpw, {Raise
On 5/9/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
snip
Yes but I think is this maybe a bug in DBI class?For example,open a file handle
and
after forking child close that handle,this would not affect parent's handle.
snip
It definitely violates the principle of least surprise, but it is also
a ve
On 5/9/2007 11:12 AM, Chas Owens wrote:
> my $dbh = DBI->connect($dsn, $dbun, $dbpw, {RaiseError => 1});
>
> to
>
> my $dbh = DBI->connect(
> $dsn, $dbun, $dbpw,
> {
> RaiseError => 1,
> mysql_auto_reconnect => 1
> }
> );
Yes, that works, just as a regular my $dbh = D
-Original Message-
>From: Chas Owens <[EMAIL PROTECTED]>
>Sent: May 10, 2007 12:02 AM
>To: Jeff Pang <[EMAIL PROTECTED]>
>Cc: beginners-list
>Subject: Re: forking problem with dbd::mysql
>
>On 5/9/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
>snip
On 5/9/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
snip
But still has a question for me.We may see this similiar destroy method on DBI
class,
sub DESTROY
{
my $self = shift;
my $dbh = $self->{'dbh'};
if ($dbh) {
local $SIG{'__WARN__'} = sub {};
$dbh->disconnect();
}
-Original Message-
>From: Chas Owens <[EMAIL PROTECTED]>
>Sent: May 9, 2007 11:25 PM
>To: Jeremy Kister <[EMAIL PROTECTED]>
>Cc: beginners@perl.org
>Subject: Re: forking problem with dbd::mysql
>
>On 5/9/07, Chas Owens <[EMAIL PROTECTED]> wrote:
>
On 5/9/07, Jeff Pang <[EMAIL PROTECTED]> wrote:
snip
This is the reason really.I was also confused for this case once.
Thanks for Chas's explain.
snip
Knowing what is happening is only half the battle, now we need to find
a non-hacky solution.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For a
-Original Message-
>From: Chas Owens <[EMAIL PROTECTED]>
>> It looks like it has something to do with $dbh going out of scope
>> (when the child exits).
>snip
>
>This is definitely a case of the database handle auto-disconnecting
>when it is destroyed. You can see the behavior by creati
On 5/9/07, Chas Owens <[EMAIL PROTECTED]> wrote:
snip
It looks like it has something to do with $dbh going out of scope
(when the child exits).
snip
This is definitely a case of the database handle auto-disconnecting
when it is destroyed. You can see the behavior by creating a set of
DBI subcl
On 5/9/07, Jeremy Kister <[EMAIL PROTECTED]> wrote:
On 5/9/2007 12:01 AM, Jeff Pang wrote:
> 1) too less timeout setting in my.cnf? see /etc/my.cnf and look for this line:
I actually have no my.cnf. But if I s/my $pid = fork()/my $pid=1/ all
works fine, even with 60 second sleeps.
> 2) as we k
On 5/8/2007 6:46 PM, Jeremy Kister wrote:
> I'm utilizing fork for the first time, and am having an issue which I
> can't track down.
I sent this original email with a bad return address. Four and a half
hours later, when the post still didnt make it to the list, I realized
that the I had used
I'm utilizing fork for the first time, and am having an issue which I
can't track down.
I've made a test program at http://jeremy.kister.net/code/ftest.pl to
demonstrate. I expect this program to print 'SQL RESULT: 1' for as long
as it can.
SQL RESULT: 1
SQL RESULT: 1
SQL RESULT: 1
DBD::mys
On 5/9/2007 12:01 AM, Jeff Pang wrote:
> 1) too less timeout setting in my.cnf? see /etc/my.cnf and look for this line:
I actually have no my.cnf. But if I s/my $pid = fork()/my $pid=1/ all
works fine, even with 60 second sleeps.
> 2) as we know,child exiting would return a SIGCHLD signal to par
-Original Message-
>From: Jeremy Kister <[EMAIL PROTECTED]>
>Sent: May 9, 2007 11:05 AM
>To: beginners@perl.org
>Subject: forking problem with dbd::mysql
>
>I'm am having an issue with a mysql connection that displays itself when
>there's fork
I'm am having an issue with a mysql connection that displays itself when
there's forking going on which I can't track down.
I've made a test program at http://jeremy.kister.net/code/ftest.pl to
demonstrate. I expect this program to print 'SQL RESULT: 1' for as long
as it can.
But instead:
SQL RE
30 matches
Mail list logo
