On Dec 4, 2007, at 5:39 PM, David Bonner wrote:
>
>
> yeah, the more i think about it, the more i realize this is an error
> when the dbapi connection is created, it's not a disconnect
> condition. the original error message is "No route to host", which
> I'm pretty sure is EHOSTUNREACH, which you get on a socket connect,
> not on a send. which means that yep, this is likely an async
> problem...the connection seems to be fine when you create it, but when
> you use it, it throws the connection error.
oh it was much weirder than that. we already do detect the
"disconnect" on usage, so thats not an issue. the issue was literally:
try:
cursor.execute(some sql)
except:
detect_disconnect_and_invalidate()
do_something()
do_something_else()
the cursor.execute would *not* raise an error. then, the program
fails, and the stack trace would say:
OperationalError: <disconnect message> at do_something_else() line 52
meaning, the stack trace originated from an *arbitrary spot* in the
application ! you could actually control it like this:
try:
cursor.execute(some sql)
time.sleep(5)
except:
detect_disconnect_and_invalidate()
do_something()
do_something_else()
the time.sleep() would change the point of exception to be within the
try/except block ! the ticket is here:
http://www.initd.org/tracker/psycopg/ticket/183
and the second email in the thread has the test script. federico
sort of thought it was a bug although i didnt follow his reasoning,
but the ticket seems pretty dead.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
