Sharing a DBI::Mysql database connection with your children

[Andrew DeFaria]

I have a process I was thinking of making into a multithreaded daemon
that deals with a MySQL database. The thought is that the daemon would
open the database once, then listen for clients. As clients connected
the daemon would fork off a copy of itself and handle the requests. This
would make the process faster because I wouldn't need to open the
database every time a new client wanted service.

However, I've found that once I fork the database handle (obtained
through DBI) is no longer valid. Reading around a little bit I noticed
people saying to reopen or reconnect to the database in the child. Well
that's the very time consuming thing I was trying to avoid!

Does anybody know how to open a MySQL database such that that database
connection can be used in forked children?

 

[Peter J. Holzer]

I have a process I was thinking of making into a multithreaded daemon ^^^^^^^^^^^^^
that deals with a MySQL database. The thought is that the daemon would
open the database once, then listen for clients. As clients connected
the daemon would fork off a copy of itself and handle the requests. This

^^^^
Do you want to use threads or fork?

would make the process faster because I wouldn't need to open the
database every time a new client wanted service.

This cannot be done. Not only will the database server get a mixture of
requests from different database clients on the same connection (this
could be solved), but it also has to send back all replies via the same
connection: Which client will receive the response? There is no way to
determine that.

(There is at least one RDBMS where the client automatically opens a new
connection when it detects a pid change - presumably the new connection
will be pre-authenticated and faster to establish).

Your best bet is probably to use a pre-forked approach like some web
servers. Run a number of your your daemons in parallel, all listening on
the same port. A client connecting to that port will get any of them.
If all are busy, the client has to wait, or a controlling process can
start more worker processes.

hp

 

[xhoster]

I have a process I was thinking of making into a multithreaded daemon
that deals with a MySQL database. The thought is that the daemon would
open the database once, then listen for clients. As clients connected
the daemon would fork off a copy of itself and handle the requests. This
would make the process faster because I wouldn't need to open the
database every time a new client wanted service.

On my system it takes less than one millisecond to open a connection
to a MySQL server (located on a different system.) Do you find that
connection time problematic? This is about the same amount of time
it takes to fork in the first place.

However, I've found that once I fork the database handle (obtained
through DBI) is no longer valid. Reading around a little bit I noticed
people saying to reopen or reconnect to the database in the child.

Yes, true.

Well
that's the very time consuming thing

I find that hard to believe.

I was trying to avoid!

Does anybody know how to open a MySQL database such that that database
connection can be used in forked children?

I don't. I rather doubt other people do, either. Maybe your server
should handle requests internally rather than forking.


Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[Dr.Ruud]

Andrew DeFaria schreef:

Does anybody know how to open a MySQL database such that that database
connection can be used in forked children?

See connect_cached and Ima:BI.

 

[szr]

On my system it takes less than one millisecond to open a connection
to a MySQL server (located on a different system.) Do you find that
connection time problematic? This is about the same amount of time
it takes to fork in the first place.

Normally this would be true, if the MySQL server is on the same network,
but if it's not, connection time depends entirely on the latency between
the OP's running system and the MySQL server, such is the case if it is
across the internet; it will surely take longer than a millisecond. But
then again, that would hardly be an ideal setup, but it's not unheard
of.

 

[Andrew DeFaria]

On my system it takes less than one millisecond to open a connection
to a MySQL server (located on a different system.) Do you find that
connection time problematic? This is about the same amount of time it
takes to fork in the first place.

I'm sorry. I didn't officially measure it. I remember another DBMS being
extremely slow so I assume it. Will you ever forgive me?

 

[A. Sinan Unur]

I'm sorry. I didn't officially measure it. I remember another DBMS
being extremely slow so I assume it. Will you ever forgive me?
--
Andrew DeFaria <http://defaria.com>
Disk Full - Press F1 to belch.

Attachment decoded: untitled-2.txt
--------------060102070906040004010008
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

I may consider it if you stop posting HTML attachments.

Sinan

--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/

 

[Tad J McClellan]

I may consider it if you stop posting HTML attachments.

Please don't tell him how to post.

http://groups.google.com/group/comp.lang.perl.misc/msg/1a331dca40c4d90a


Nobody else here ignores that netiquette, simply spend your
time answering their questions instead.