[note: This discussion went on off-list, but I thought the info might
be useful in list context, so I am reposting it to the list. Sorry
about the lack of individual messages. I wish gmail had an option to
automatically add an address to a reply when you are replying to a
message that has been assigned a label. I've requested the feature in
fact. ]
I didn't say it can't be done. I said you have to be _very_ careful.
You can't use the connection in both the parent and the client. If
you connect in the parent, then don't do anything with that connection
handle. Let the client do all the work with that connection. If you
don't do that you have an absolute recipe for disaster. You need to
have one connection per child. It simply won't work otherwise. That
isn't to say you can't create one connection for each child in the
parent process and pass it through fork (more on that below). Just
don't cross the streams, it will be _very bad_. Close the connection
after the child ends. Don't close the connection in the child.
The same logic applies to other file descriptors. If you pass a
socket to a child process, then you close the child in the parent and
you don't try to do anything else with it. If you don't close it, you
will eventually run out of file descriptors. The difference is that
closing a database involves more than just closing a file descriptor.
Database connections, well actually the database access layers, such
as PHP and PERL/DBI, do a lot of background work that is obfuscated
from the user.
This includes automatically closing file handles, database
connections, statement handles, etc. If you close your handle in the
client, and the client library automatically issues a COMMIT and
closes the connection, then you kill the child and the parent also
tries to close the connection (probably because the connection has
gone out of scope) then you are going to have problems.
This is why I said, when you use Perl/DBI you need to make sure
InactiveDestroy is set correctly in the parent and the child. This
prevents that background voodoo from going on in DBI and ensures
that you don't run into problems. You will need to do similar
synchronization in other languages to ensure that your children and
your parent get along.
My philosophy is that you should destroy the connection in the same
thread/process/whatever that created the connection. This ensures
that resources are released properly.
Now, all that said, I truely believe that the best way to do things is
probably the easiest way. In general it is much easier, and you are
goign to have less bugs, if you just connect in the child. If you are
connecting in the parent, because the child doesn't normally know what
database to connect to, then just set a variable with the connection
details (dsn/connect string/etc) and let the child connect on it's own
using that.
On Sun, 1 Aug 2004 12:02:30 -0700, bruce [EMAIL PROTECTED] wrote:
since you're saying you can't share the connection, could you please tell me
where in the docs it states you can't, and the reason(s) for not being able
to 'share'.
i would believe that once you make the connection, you should be able to
'use' it between any process that can get 'access' to it.
so my initial question still stands, how can it be accomplished, or why it
can't be done.
i'm inclined to believe that if you can create a db connection handle, then
any other process should be able to use it, as long as the creating
process/parent process is still alive/running
-bruce
-Original Message-
From: Justin Swanhart [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 01, 2004 11:53 AM
To: [EMAIL PROTECTED]
Subject: Re: a question/issue...
In general, it is probably a bad idea to inherit database connections
from a parent in a fork()'ed child process.
What is your reasoning behind not permitted the children to make their
own connection?
If you can not connect from the child and you must inherit a database
connection from the parent, make sure you create a new connection for
each child. You can't share the same connection between the parent
and the child. If you use the connection in the parent do not use it
in the child and vice versa.
If you are using perl DBI then you need to set InactiveDestroy where
it makes sense to do so. See the DBI manual for details. You will
need to take similar measures in other environments.
..
On Sun, 1 Aug 2004 09:22:21 -0700, bruce [EMAIL PROTECTED] wrote:
hi...
i'm testing an app where i want a parent app to create the mysql db
connection link/handle, and basically pass this handle off to child
procesess. is there any reason why this can't be done? are there any
examples of this already being accomplished that you might provide???
as far as i can tell/see, it should be possible. as long as the parent is
still running, the connection link/handle should still be valid.
i'm going to ultimately
