-----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

Reply via email to