Hi Jason > Why are you assigning this as a MySQL design flaw? We've designed > quite a few InnoDB apps that handle just this situation very well in > event of a rollback.
When your applications notice that the connection is lost, they also know that transactions where rolled back and they can either try to establish a new connection and redo the transaction or exit. Your applications know what has happend! Contrary, if the MySQL client library does a reconnection silently, your applications don't know that the transactions were rolled back. They assume they are still in the middle of the transaction and keep going changing records. Unfortunately, the reestablished connection is set to the default state which means that no transaction is in progress and auto-commit is turned on. All changes will be permanent immediately and if you send a ROLLBACK statement to the database, nothing will happen. In case of a COMMIT, you've lost the changes up to the reconnect (which you haven't noticed). This leads to errors which are almost impossible to detect and therefore I consider this feature a design flaw if it's enabled by default. It makes only sense if you are only reading from a database and don't use transactions or locks. Norbert -- OpenPGP public key http://www.linuxnetworks.de/norbert.pubkey.asc
pgppX4YYK2Ctt.pgp
Description: PGP signature
_______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
