[ https://forge.continuent.org/jira/browse/SEQUOIA-910?page=comments#action_13679 ]
Mark Matthews commented on SEQUOIA-910: --------------------------------------- This is the Connector/J maintainer here. I'm confused how your code could see any of the java.net.*Exceptions thrown from Connection.getTransactionIsolation(), since they're all checked exceptions, and getTransactionIsolation() doesn't declare that it throws them. Are you sure you're not looking at a SQLException which is wrapping the underlying exception and are just confused by what toString() reports? (see my reply in http://bugs.mysql.com/bug.php?id=26022), where I show that it's a SQLException that's thrown from the driver. Looking at the sequoia list posting, I'm still confused again, because once again, you're looking at a checked exception, so something's "editorializing" the stack trace and leaving out the top-level exception, or there's confusion in your log. Anything method you call in JDBC has SQLException as the only checked exception declared (I'm almost 100% sure on that), and the exceptions you're seeing here are _not_ runtime/unchecked exceptions. Just to be sure, don't trust the log, and set a breakpoint in a debugger, and see what class of exception you're _really_ getting. > Undetected recovery log failure causes a major problem in replication > --------------------------------------------------------------------- > > Key: SEQUOIA-910 > URL: https://forge.continuent.org/jira/browse/SEQUOIA-910 > Project: Sequoia > Type: Bug > Components: Core > Versions: Sequoia 3.0 > Reporter: Guillaume Smet > > > This is a followup of the thread > https://forge.continuent.org/pipermail/sequoia/2007-February/004683.html on > sequoia list. > In RecoveryLog.getDatabaseConnection(), Sequoia catches RuntimeException and > SQLException but not others. In the case of RuntimeException and > SQLException, a problem to establish the connection is correctly handled > (inserts in the recovery log are postponed) but not in the case of a > ConnectException for instance. > In the case reported by Gérard Bunel, the MySQL server hosting the recovery > log is shutdown and it throws a java.net.ConnectException. Write queries are > not logged in this recovery log and the failure of the recovery log is not > detected by Sequoia. This leads to a synchronisation problem when restarting > the recovery log and enabling the backend as the recovery logs of both > controllers are not identical. > IMHO we should catch every Exception instead of just SQLException in the last > catch of getDatabaseConnection(). > Thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://forge.continuent.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
