3 messages in com.mysql.lists.javaRe: Failover and autoReconnect only w...
FromSent OnAttachments
Kevin Burton02 Jun 2004 14:08 
Mark Matthews02 Jun 2004 14:32 
Kevin Burton02 Jun 2004 16:56 
Subject:Re: Failover and autoReconnect only work when the connection is in a autoCommit(false) state, in order to stay transaction safe?
From:Mark Matthews (ma@mysql.com)
Date:06/02/2004 02:32:29 PM
List:com.mysql.lists.java

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Kevin Burton wrote:

Is this true still?

Kind of seems to defeat the whole purpose when using MyISAM tables.

Kevin,

Reconnect and failover only works when autoReconnect == true. (Hopefully I didn't post it somewhere the other way around).

This still works when using transactions, because the JDBC spec requires that connections are in autoCommit == true state when created, so almost all connection pools issue a setAutoCommit(true) before handing out a connection, which will toggle the re-connect (or failover, if configured to do so) if an error occured during the last 'transaction'.

It is not wise to reconnect when autoCommit == false, because your application is assuming that transactions are there, and that data will be consistent...this is not the case during re-connect or failover, because the current transaction will be implicitly rolled back when the connection is dropped, but your application will plod blindly on assuming that data is in the state it was when the connection failed.

If you want my opinion, don't use autoReconnect at all unless you're using it for failover or clustering (it's a crutch for older connection pools, and applications that don't check for SQLExceptions and deal with them).

The JDBC spec doesn't specify that connections live forever (this has been checked with other vendors and the JDBC spec lead), that's one reason why SQLStates are exposed in SQLExceptions, and why there are also SQLStates that represent a connection failure ('08S01' in the case of Connector/J). It is also why ConnectionPoolDataSources fire connection error events...If your connection pool implementation or application is not making use of either of these features, it's probbably not using JDBC as intended, at least in dealing with possible failures.

See the following example of how to deal with a connection failure and re-try your transaction:

http://dev.mysql.com/doc/connector/j/en/index.html#id2805225

-Mark

- -- Mr. Mark Matthews MySQL AB, Software Development Manager, J2EE and Windows Platforms Office: +1 708 332 0507 www.mysql.com

MySQL Guide to Lower TCO http://www.mysql.com/it-resources/white-papers/tco.php -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAvkeCtvXNTca6JD8RAls2AJ9e8JyWc7xzuUbbC6MtiCBBtyi3/wCffkK9 OzAAt9RKddO93DN2FpSpPu0= =vN6z -----END PGP SIGNATURE-----