ok i REALLY cant narrow down the exact thing that causes this to happen with MySQLdb. I have gone through pool.py carefully, adding flags and assertions to the code to insure that its not sharing connections *or* cursors between threads; its not. all cursors are closed before the connection is ever returned to the pool. running a small WSGI-based benchmark, i can consistently get the "mysql server has gone away" errors as well as "commands out of sync". running the same benchmark with postgres has no issues.
So i have checked in a fix in 2132 that does not prevent the error but *does* keep it from being catastrophic, and its that the mysql dialect catches error code 2006 and 2014 and invalidates the connection before re-throwing the error, so that at least the pool doesnt get filled up with busted connections. as far as SingletonThreadPool, its not a terrific default setting since for an applciation that keeps opening new threads (as some web containers do), youre going to be opening new connections all the time. also i think this issue is also platform-specific to some degree as some colleagues on irc are unable to reproduce the problem on their linux machines. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
