On Sep 19, 2009, at 5:29 PM, jeff.enderw...@gmail.com wrote:
> > Thanks for the links. It seems that the proposed soln to the mysql 8hr > idle connection time is: > a) recycle connections before they can be clipped by mysql, > b) extend the mysql timeout interval (aggregating what I've seen in > other postings across the 'net). > > Would it make sense to actually re-try at the point of failure, and if > the connection cannot be established, *then* raise the exception? > It seems like having a recovery mechanism could help with true > spurious disconnects as well. re-trying at the point of failure is a valid strategy but not something SQLAlchemy can do implicitly. It does not keep a log of all operations which were processed in a particular transaction such that it can re-issue the same series of events which were lost in the previous transaction. Even if it could, its very possible that on the second run the state of the database is different, and that it wouldn't even be appropriate to re-run the same sequence of events. more realistically, a web request would fail, then the user would try again which would begin a new request and start with a new connection. so the reconnect logic allows that if you restart your database while the web app is running, you get some errors but not a catastrophic failure. > > Jeff > > On Sep 16, 8:00 am, "Michael Bayer" <mike...@zzzcomputing.com> wrote: >> Teemu Yli-Elsilä wrote: >> >>> Hello, >> >>> I'm deploying a Pylons/TG app that uses SQLAlchemy into a customer's >>> server network. Due to their network architecture, TCP sessions >>> from SA >>> to the Oracle server are getting timed out by their Ciscos. My >>> application needs to work around this. >> >>> I heard that Mike Bayer had stated that SQLAlchemy won't be able >>> to cope >>> with database outages properly, however, the next request after a >>> timeout/disconnection will try again. I assume this is causing the >>> sporadic errors I am receiving, such as: >> >>> "AttributeError: 'unicode' object has no attribute >>> '_sa_instance_state'" >>> inside sqlalchemy.orm.attributes >> >>> 'UndefinedError: None has no member named "name"' from a Genshi >>> template >>> containing $item.name where 'item' is a model class instance. >> >> actually no, neither of those errors would be caused by a database >> outage. >> If aconnectiondied, an exception would be thrown and your entire >> request >> would fail with a 500 server error. Stack traces would be thrown and >> you'd see those very plainly in your logs. >> >> If you were wrapping the retreival of data in a try/except and then >> returning None if an exception occurred (an *extremely* bad idea), >> that >> might cause the second error of those two, but still not the first. >> >> >> >>> Is there a way to configure aconnectionkeepalive, regular pinging of >>> the DB, or otherwise make sure that pool connections are recycled >>> within >>> a given time limit? >> >> recycle is documented at these locations: >> >> http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/ >> connections.ht... >> >> http://www.sqlalchemy.org/trac/wiki/FAQ#Howdoespool_recyclework >> >> http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/ >> pooling.html#s... >> >> the "ping" feature you can implement using a PoolListener, which is >> described here (this is a more obscure feature): >> >> http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/ >> interfaces.htm... >> >> hope this helps. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
