Thanks Mike!!! Good stuff. These errors are happening in production on a financial system that I wrote, but to which I do not have live access for security, liability and policy reasons. So I can't inspect the internal state of the server myself (and the SA with clearance won't go out of his way), but from reading the links you sent, it seems the two most generic / widely-applicable fixes that are likely to help would be to:
Switch from READ UNCOMMITTED to READ COMMITTED and increase the setting for innodb_lock_wait_timeout to something greater than 50 (eg 300) One of the threads also points out that if some code with DB changes (updates/deletes) falls off without ever committing, that MySQL will sleep that thread for up to the length of *wait_timeout *(default of 8 hours) BUT STILL leave all of those rows locked the entire time......I wonder if one of our scheduled stored procs might be doing this since I don't think the client is making that mistake..... Thanks for pointing me in the right direction!! -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
