Hi, >What it doesn't handle is if the database server is restarted. That >doesn't happen very often with reliable database servers nowadays but >it is possible. > > Yes, this is something of a problem for long-running apps that used pooled database connections.
I did some work with Mike a few months back, so that SA notices a dropped connection exception and invalidates the connection. The current statement fails, but at least subsequent requests in that thread can succeed. You could put "select 1" at the start of all your requests, acting as a "ping". You can just ignore errors in the ping - SA will reconnect automatically. That's a bit of a performance hit, so I wonder if we can do any better. The reason for not retrying the failed statements is that there could be transactional state which would be lost. However, perhaps SA could keep track of whether there is transactional state. If there isn't any, it can retry the statement safely. Perhaps make this behaviour not the default and make people turn it on with an option. Considering that the problem will almost always happen on the first db query in a request, that will fix almost all cases without needing a ping. I might have a go at coding this up in the next couple of weeks. Paul --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
