Use the latest 0.6 release, MySQL reconnect detection had a bug up until 0.6.5.
When a disconnect occurs, you need to suffer at least one exception throw.
When it occurs, the engine then disposes its pool of connections. The
subsequent connections will the proceed assuming the DB is back up.
On Dec 9, 2010, at 1:11 PM, Mynnx wrote:
> I'm writing a daemon that constantly manipulates a database, and needs
> to be able to keep chugging along if MySQL is restarted or becomes
> (dis/re)connected for some reason. I've been testing this behavior
> and I can't quite figure out how to make it consistently work.
>
> I get repeated OperationalError('MySQL server has gone away') errors
> when I restart MySQL during execution and then try to run queries.
> Calling session.close() doesn't resolve the errors; I've found that
> only creating/using a new Engine seems to let it continue. This is
> probably because of connection pooling - I think SQLA is just pulling
> dead connections out of the pool and trying to use them.
>
> I feel like destroying the Engine is a little heavy-handed and that I
> should just be able to tell the pool "hey, all your connections aren't
> tied to the database any more; drop those and start pooling again
> please." What do you recommend?
>
> --
> 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.
>
--
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.
