DBD::mysql fork() problem

hello guys,

after upgrading DBD::mysql from 2.1026 to 2.9002 i ran into the problem that after a fork(), the child looses connection to the database.
i've read the discussion on this list about multiple access on a single db handle, but this is how fork() is working. due to internal issues, i cant connect to the database AFTER the fork(). i dont see why this behaviour was changed, as if one just lets the parent die to daemonize a process, things are fine. its how fork() works and if one would not like to have various instances using the same handle, just dont do it this way.

or maybe i just overlook an important reason for it.

regards,
h. steuer




--
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD::mysql fork() problem

imho to share a single connection between serveral processes is not a good=
idea
anyway.
after fork() you can disconnect and reconnect, thus creating a new
database handle for the child process.


On 15 Sep 2003 at 13:41, H. Steuer wrote:

> hello guys,
>
> after upgrading DBD::mysql from 2.1026 to 2.9002 i ran into the problem =
that after a fork(), the child looses connection to the database.
> i've read the discussion on this list about multiple access on a single =
db handle, but this is how fork() is working. due to internal issues, i c=
ant connect to the database AFTER the fork(). i dont see why this behavio=
ur was changed, as if one just lets the parent die to daemonize a process,=
things are fine. its how fork() works and if one would not like to have v=
arious instances using the same handle, just dont do it this way.
>
> or maybe i just overlook an important reason for it.
>
> regards,
> h. steuer
>
>
>
>
> --
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail in e=
rror)
> please notify the sender immediately and destroy this e-mail. Any unauth=
orized
> copying, disclosure or distribution of the material in this e-mail is st=
rictly
> forbidden.
>
> --
> MySQL Perl Mailing List
> For list archives: http://lists.mysql.com/perl
> To unsubscribe: http://lists.mysql.com/perl?unsub=3Dubo1@gmx.de
>


MfG
Ulrich Borchers

--
Dipl.-Inf. Ulrich Borchers
MEGABIT Informationstechnik GmbH
Karstr. 25, 41068 Mönchengladbach
Tel. +49 2161 30898-28



--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD::mysql fork() problem

imho to share a single connection between serveral processes is not a good=
idea
anyway.
after fork() you can disconnect and reconnect, thus creating a new
database handle for the child process.


On 15 Sep 2003 at 13:41, H. Steuer wrote:

> hello guys,
>
> after upgrading DBD::mysql from 2.1026 to 2.9002 i ran into the problem =
that after a fork(), the child looses connection to the database.
> i've read the discussion on this list about multiple access on a single =
db handle, but this is how fork() is working. due to internal issues, i c=
ant connect to the database AFTER the fork(). i dont see why this behavio=
ur was changed, as if one just lets the parent die to daemonize a process,=
things are fine. its how fork() works and if one would not like to have v=
arious instances using the same handle, just dont do it this way.
>
> or maybe i just overlook an important reason for it.
>
> regards,
> h. steuer
>
>
>
>
> --
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail in e=
rror)
> please notify the sender immediately and destroy this e-mail. Any unauth=
orized
> copying, disclosure or distribution of the material in this e-mail is st=
rictly
> forbidden.
>
> --
> MySQL Perl Mailing List
> For list archives: http://lists.mysql.com/perl
> To unsubscribe: http://lists.mysql.com/perl?unsub=3Dubo1@gmx.de
>


MfG
Ulrich Borchers

--
Dipl.-Inf. Ulrich Borchers
MEGABIT Informationstechnik GmbH
Karstr. 25, 41068 Mönchengladbach
Tel. +49 2161 30898-28



--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD::mysql fork() problem

Hi Uli,

thanks for your answer. in fact thats how fork() is supposed to be.
if its a good idea or not to share handles depends on various things and exceeds the topic of this discussion. i just wonder why this module was working as expected and this behaviour was changed.

regards,
h. steuer


On Mon, 15 Sep 2003 14:15:32 +0200
"Ulrich Borchers" wrote:

> imho to share a single connection between serveral processes is not a good idea
> anyway.
> after fork() you can disconnect and reconnect, thus creating a new
> database handle for the child process.
>
>

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD::mysql fork() problem

Hi Uli,

thanks for your answer. in fact thats how fork() is supposed to be.
if its a good idea or not to share handles depends on various things and exceeds the topic of this discussion. i just wonder why this module was working as expected and this behaviour was changed.

regards,
h. steuer


On Mon, 15 Sep 2003 14:15:32 +0200
"Ulrich Borchers" wrote:

> imho to share a single connection between serveral processes is not a good idea
> anyway.
> after fork() you can disconnect and reconnect, thus creating a new
> database handle for the child process.
>
>

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD::mysql fork() problem

H. Steuer wrote:

> thanks for your answer. in fact thats how fork() is supposed to be.
> if its a good idea or not to share handles depends on various things
> and exceeds the topic of this discussion. i just wonder why this
> module was working as expected and this behaviour was changed.

I am not so sure, whether reusing a MySQL connection in a forked child is
supposed to work. We have to distinguish between reusing sockets and reusing
database connections.

If the parent has a socket and forks a child, then the operating system
*knows*, that the socket is still open. In other words, the first close() is
just internally and suppress sending a shutdown to the remote end.

If the parent has a database connection and forks a child, then the database
driver *does not know* that the connection exists in a separate process.
This won't matter, if a disconnect() is simply a shutdown of the socket: The
operating system can still suppress the shutdown, if required. However, if
a disconnect implies a "good bye message" sent by the client, then the
disconnect() in either process will trigger that good bye message, making
the connection unusable for the second process as well.

In other words, whether a connection can be used in a forked child, will
almost definitely vary between database drivers and even versions. I do not
know what's specifically changed in 2.9002, but I would assume that you
recompiled the driver, because other things (for example the MySQL client
library) have changed as well on your systems. If so, I would rather see you
querying on the MySQL mailing list first, whether fork() is indeed to work
as you are expecting or not.


Jochen



--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD::mysql fork() problem

H. Steuer wrote:

> thanks for your answer. in fact thats how fork() is supposed to be.
> if its a good idea or not to share handles depends on various things
> and exceeds the topic of this discussion. i just wonder why this
> module was working as expected and this behaviour was changed.

I am not so sure, whether reusing a MySQL connection in a forked child is
supposed to work. We have to distinguish between reusing sockets and reusing
database connections.

If the parent has a socket and forks a child, then the operating system
*knows*, that the socket is still open. In other words, the first close() is
just internally and suppress sending a shutdown to the remote end.

If the parent has a database connection and forks a child, then the database
driver *does not know* that the connection exists in a separate process.
This won't matter, if a disconnect() is simply a shutdown of the socket: The
operating system can still suppress the shutdown, if required. However, if
a disconnect implies a "good bye message" sent by the client, then the
disconnect() in either process will trigger that good bye message, making
the connection unusable for the second process as well.

In other words, whether a connection can be used in a forked child, will
almost definitely vary between database drivers and even versions. I do not
know what's specifically changed in 2.9002, but I would assume that you
recompiled the driver, because other things (for example the MySQL client
library) have changed as well on your systems. If so, I would rather see you
querying on the MySQL mailing list first, whether fork() is indeed to work
as you are expecting or not.


Jochen



--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD::mysql fork() problem

I'm afraid I don't know about version specific differences of DBD::mysql
and if the driver can deal with fork() as you expect it to.
But I ran into this problem before. In fact mysql "went away" when
serveral child processes used the same handle AT THE SAME TIME.

fork() does not know about mysql. it makes a copy of a variable which in t=
his
case is a reference to the same mysqld process (?). I think that each proc=
ess
needs its own connection. Otherwise mysql could not handle concurrent
queries (over the same handle).

On 15 Sep 2003 at 14:20, H. Steuer wrote:

> Hi Uli,
>
> thanks for your answer. in fact thats how fork() is supposed to be.
> if its a good idea or not to share handles depends on various things and=
exceeds the topic of this discussion. i just wonder why this module was w=
orking as expected and this behaviour was changed.
>
> regards,
> h. steuer
>
>
> On Mon, 15 Sep 2003 14:15:32 +0200
> "Ulrich Borchers" wrote:
>
> > imho to share a single connection between serveral processes is not a =
good idea
> > anyway.
> > after fork() you can disconnect and reconnect, thus creating a new
> > database handle for the child process.
> >
> >
>


MfG
Ulrich Borchers

--
Dipl.-Inf. Ulrich Borchers
MEGABIT Informationstechnik GmbH
Karstr. 25, 41068 Mönchengladbach
Tel. +49 2161 30898-28



--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD::mysql fork() problem

I'm afraid I don't know about version specific differences of DBD::mysql
and if the driver can deal with fork() as you expect it to.
But I ran into this problem before. In fact mysql "went away" when
serveral child processes used the same handle AT THE SAME TIME.

fork() does not know about mysql. it makes a copy of a variable which in t=
his
case is a reference to the same mysqld process (?). I think that each proc=
ess
needs its own connection. Otherwise mysql could not handle concurrent
queries (over the same handle).

On 15 Sep 2003 at 14:20, H. Steuer wrote:

> Hi Uli,
>
> thanks for your answer. in fact thats how fork() is supposed to be.
> if its a good idea or not to share handles depends on various things and=
exceeds the topic of this discussion. i just wonder why this module was w=
orking as expected and this behaviour was changed.
>
> regards,
> h. steuer
>
>
> On Mon, 15 Sep 2003 14:15:32 +0200
> "Ulrich Borchers" wrote:
>
> > imho to share a single connection between serveral processes is not a =
good idea
> > anyway.
> > after fork() you can disconnect and reconnect, thus creating a new
> > database handle for the child process.
> >
> >
>


MfG
Ulrich Borchers

--
Dipl.-Inf. Ulrich Borchers
MEGABIT Informationstechnik GmbH
Karstr. 25, 41068 Mönchengladbach
Tel. +49 2161 30898-28



--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD::mysql fork() problem

On Mon, 15 Sep 2003, H. Steuer wrote:

> hello guys,
>
> after upgrading DBD::mysql from 2.1026 to 2.9002 i ran into the problem
> that after a fork(), the child looses connection to the database. i've
> read the discussion on this list about multiple access on a single db
> handle, but this is how fork() is working. due to internal issues, i
> cant connect to the database AFTER the fork(). i dont see why this

This behaviour was not changed, per se; however, It might be that the
chage to the auto-reconnect behaviour is exposing a bug in your code. In
2.1026 if DBD::mysql got a "Server has goin away" error message,
DBD::mysql would just go and reconnect to the database for you and
basically ignore the error. The problem with this is that any locks would
be lost and the application would not know it.

> behaviour was changed, as if one just lets the parent die to daemonize a
> process, things are fine. its how fork() works and if one would not like

Well did you set InactiveDestroy? Because if you do not, when that
connection goes out of scope in the parrent, it will call the DESTROY
method which will disconnect from the server.

And FWIW, I have seen weird behaviour when 2 processes try to access a
shared $dbh concurrently.

Rudy


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD::mysql fork() problem

On Mon, 15 Sep 2003, H. Steuer wrote:

> hello guys,
>
> after upgrading DBD::mysql from 2.1026 to 2.9002 i ran into the problem
> that after a fork(), the child looses connection to the database. i've
> read the discussion on this list about multiple access on a single db
> handle, but this is how fork() is working. due to internal issues, i
> cant connect to the database AFTER the fork(). i dont see why this

This behaviour was not changed, per se; however, It might be that the
chage to the auto-reconnect behaviour is exposing a bug in your code. In
2.1026 if DBD::mysql got a "Server has goin away" error message,
DBD::mysql would just go and reconnect to the database for you and
basically ignore the error. The problem with this is that any locks would
be lost and the application would not know it.

> behaviour was changed, as if one just lets the parent die to daemonize a
> process, things are fine. its how fork() works and if one would not like

Well did you set InactiveDestroy? Because if you do not, when that
connection goes out of scope in the parrent, it will call the DESTROY
method which will disconnect from the server.

And FWIW, I have seen weird behaviour when 2 processes try to access a
shared $dbh concurrently.

Rudy


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org