-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan,
On 1/26/12 12:45 PM, Daniel Mikusa wrote: > I agree that it looks like you have specified autoReconnect > correctly, but I'm no expert there. +1 autoReconnect has been specified properly, but you have to understand what it does: autoReconnect causes a failure for the connection attempt and throws an exception, but also re-connects after the exception. I think that's totally stupid behavior, but it's what's documented and actually what happens, so... > I believe that autoReconnect is a feature of the JDBC driver, so > you might want to check with the MySQL folks to see why that is not > working. +1 See above. The Connector/J folks both highly recommend against using autoReconnect (http://dev.mysql.com/doc/refman/5.5/en/connector-j-reference-configuration-properties.html): " autoReconnect: [...] The use of this feature is not recommended, because it has side effects related to session state and data consistency when applications don't handle SQLExceptions properly, and is only designed to be used when you are unable to configure your application to handle SQLExceptions resulting from dead and stale connections properly. " and at the same time, obviously recommend using it (based upon the exception detail message you got, plus all the documentation for clustering and failover, etc.). My recommendation is to stop using it, and instead use: >> I also know I could (and probably should) add defensive code to >> check for connection validity. But again, this all worked fine >> for years on 5.0. > > Have you tried using the validation offered by the connection > pool? > > If you set "testOnBorrow=true" and "validationQuery=SELECT 1", the > pool should validate connections without requiring any code changes > to your application. +1 This is a much better way to do things: DBCP can handle everything for you, here. A better validation query is "/* ping */SELECT 1" because newer versions of the Connector/J driver do a low-effort "ping" to the server[1] instead of actually issuing an SQL query and all the overhead that entails. Sure, "SELECT 1" doesn't exactly have a high cost compared to the query you are likely about to run, but every little bit of performance helps. - -chris [1] http://dev.mysql.com/doc/refman/5.5/en/connector-j-usagenotes-troubleshooting.html#qandaitem-22-3-11-1-12 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8hnuIACgkQ9CaO5/Lv0PB7qACcCObIxAcTCk/FNHEhsZP/xqzL d4sAoIF3ay+0lORb7l12c5J/tUPZj6R6 =OcHQ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org