On 6/1/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > the latest version of MySQLDB does use weakrefs right at the heart of > things, in connections.py and cursors.py. since we are catching the > exception we cant see the full original stack trace but its possible > that it would trace into mysqldb's source code. > > that doesnt rule out that we are doing something to cause this to > happen in SA, but im pretty sure people are using pool_recycle with > mysql successfully.
Well, IF the problem does not go away I guess I'll have to restart the application every few hours. But with debug=false an external program can't tell if an "Internal Server Error" is this or something else, so do I, um, grep the error log? ... Hmm. I could somehow catch the error and deliver a slightly different error message (perhaps using JJ's case-modified headers secret code :), but then I might as well just restart the application... however one might do that within the application. Could I just refresh the connection pool or expire all the connections without disrupting the rest of the application? But I guess all of MySQLdb would need to be reinitialized, wouldn't it. What about a monitor process like "--reload": could it somehow be made to know when this error occurs and restart the subprocess if so? Why can't SQLAlchemy catch this and the gone-away error, refresh the connection, and redo the query like SQLObject does? That's really what one wants, not a pool_recycle time. I think you said that's incompatible with transactions but I don't see how. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
