[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 be working in perl/php/c but if i can get it > working > > in one language, i can get it in the others as well.... > > > > any thoughts/comments/criticisms/etc.... > > > > thanks > > > > -bruce > > > > -- > > MySQL General Mailing List > > For list archives: http://lists.mysql.com/mysql > > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > > > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
