On Nov 8, 2011, at 2:05 AM, Tarek Ziadé wrote: > On Tue, Nov 8, 2011 at 6:59 AM, Michael Bayer <[email protected]> > wrote: >> OK, here's my attempt. Takes place pretty much at the pool level and is >> not too intrusive, also leaves in place all the existing reconnect stuff >> which should just work as is, not to mention leaves "creator()" in place >> which also has some exception handling. I'm hoping you can test it out >> and grok the general idea in case it needs adjustment, and if we can write >> full tests it can be part of the distribution too, maybe as an ext. > > Oh wow, thanks a lot Michael. That looks much cleaner. I'll integrate > it in our codebase and see if I can complete the tests. We will bench > it in our infra to see how it goes with the real Sync app/data. > > For the reconnect stuff, I am not sure to understand how things > currently work: in case of a connection error in MySQL (2013 and the > likes) the engine.execute() method will throw the error and unless I > have done things wrong, the error bubbles up and the pool does not > attempt to recreate a new connection and run the query again.
OK so statement executions occur in engine/base.py, usually inside of _execute_context(): http://hg.sqlalchemy.org/sqlalchemy/file/ff6c45b45e60/lib/sqlalchemy/engine/base.py#l1583 Exceptions are all caught here, and passed to _handle_dbapi_exception: http://hg.sqlalchemy.org/sqlalchemy/file/ff6c45b45e60/lib/sqlalchemy/engine/base.py#l1634 http://hg.sqlalchemy.org/sqlalchemy/file/ff6c45b45e60/lib/sqlalchemy/engine/base.py#l1727 the exception itself is run through the dialect's is_disconnect() method. if this returns True, the entire pool is disposed: http://hg.sqlalchemy.org/sqlalchemy/file/ff6c45b45e60/lib/sqlalchemy/engine/base.py#l1754 and the exception, re-raised, will have the "connection_invalidated" flag set: http://hg.sqlalchemy.org/sqlalchemy/file/ff6c45b45e60/lib/sqlalchemy/exc.py#l219 the MySQL dialects all have a DBAPI-specific way to get at the error message, and examine whether or not its a "disconnect". The 2013 code is then checked here: http://hg.sqlalchemy.org/sqlalchemy/file/ff6c45b45e60/lib/sqlalchemy/dialects/mysql/base.py#l1826 There was a bug regarding this on the MySQL side that was fixed in 0.6.3 in case you're on a very old version. There's no feasible way a database tool could transparently "try the query again" - a new connection means the transaction has been discarded. It would also require silently squashing very severe errors which can't be assumed to be recoverable. But your own code can check the connection_invalidated flag on the raised exception. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
