The flag is there to help automate the renegotiation of a broken connection by allowing the client library to "conceal" from the controlling application the fact that the connection went away (for any reason).
Let's imagine that your client needs to update 3 tables. It makes a connection then loses it after only updating the first table. If all 3 sets of changes needed to happen in a transaction, you need to start over because your transaction was rolled back for you when the original connection died. In this case an "auto-reconnect" feature may actually get in the way of proper error recovery. Your application needs to know that the connection died so that it can restart the transaction from the beginning. However, if you are importing lots of data into MyISAM tables (or running lots of queries) and you drop a connection mid-transfer (no transaction needed) then you could very easily pick up where you left off once the connection comes back. In this case having a quiet, automated reconnection occur for you within the client library would be a good thing. Your application would not know that the original connection had been lost as it was reconnected transparently by the client library. Notice that I keep stressing that the client library has this flag. If you linked your application through the 3.23.58 library (lots of ways to do that) then you need to change something in your application to take advantage of the new features presented by your shift to 4.0.24. Just out of curiosity, why didn't you choose to upgrade to a 4.1.x version? Shawn Green Database Administrator Unimin Corporation - Spruce Pine "Betty Trakimas" <[EMAIL PROTECTED]> wrote on 11/22/2005 12:36:19 PM: > Thanks Shawn. Do you know why anyone would ever need the reconnect flag > then? The MySQL developers must think that it has a purpose since they > opened up the API to allow access to it from the client. What would be its > purpose otherwise? > > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: "Betty Trakimas" <[EMAIL PROTECTED]> > Cc: <mysql@lists.mysql.com> > Sent: Tuesday, November 22, 2005 12:06 PM > Subject: Re: Setting the reconnect flag in MySQL 4.0.24 > > > > "Betty Trakimas" <[EMAIL PROTECTED]> wrote on 11/22/2005 11:08:51 AM: > > > >> Hello, > >> > >> We just upgraded from 3.23.58 to 4.0.24. Our database connection, which > > can > >> remain open for a very long time, is timing out after being idle > > overnight, > >> where it never had in 3.23.58. I learned from the manual that there is > > a > >> global variable WAIT_TIMEOUT, which appears to be set at 28800 seconds > > (8 > >> hrs) by default. I can set this value to some larger amount, say 7 > > days, > >> but that may not be long enough depending on how our customers use our > >> product. In version 5.0.13 I can call mysql_options() with > >> MYSQL_OPT_RECONNECT set to true to enable automatic reconnection to the > >> server if the connection has been lost. I think this is really what I > > want > >> to do instead of setting the WAIT_TIMEOUT variable to a large value. Is > > > >> there any way to set this reconnect flag in the 4.0.24 version > >> programatically? How? > >> > >> Betty > >> > > > > Any application that depends on a connection to another application in > > order to function correctly should be robust enough to deal with the > > temporary or permanent loss of that connection without causing too much of > > a problem. It doesn't matter what kind of other application your > > application needs to connect with, if it cannot handle a loss of > > communications without breaking it is poorly designed. > > > > The reconnect flag is part of the client (your application) and how it > > makes its connection to the MySQL server. RTFM for the specific library > > your application is using for it's MySQL connectivity. It will have > > details on how to manage that flag. > > > > Most server-friendly applications only make connections when they need > > something. Tying up a network socket overnight for little or no traffic > > just wastes server-side resources. I am not recommending a new connection > > for EVERY query, once per process is generally enough. I am recommending > > that you look at your original application's design and fix it so that > > your users won't complain every time it loses connectivity with the > > database on the back end. There are more causes of LOC (loss of > > communication) other than the server reaching it's timeout value so fixing > > that will improve the overall reliability of your application. > > > > Shawn Green > > Database Administrator > > Unimin Corporation - Spruce Pine > > > > > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] >
