> The process_task method makes use of get_lock and release_lock under MySQL. > Unfortunately, these are not transaction safe. It is possible that the > getmail process failed, aborting the transaction, and leaving the lock open. > As Zope does connection pooling with ZMySQLDA, this will hold the lock > indefinitely, until that connection is reset.
That might explain why it starts working again when I restart zope. > If you wanted to submit a patch for an alternative locking mechanism for > MySQL 5, that would be appreciated. For now, if you raise a bug on sf it > will be looked at, but I cannot see an immediate fix to this issue. Why do the locking in the DB in the first place? Assuming that the purpose of the lock is to be sure that two copies of the script don't run, why not just create a lockfile somplace (/var? /tmp? something configurable?) and use it via std. lockfile semantics? Alternatively, you can just wrap the body of the script in a big exception handler (assuming Python has such a thing) which starts just after you get the lock and ends just before you release the lock. That way, you can be assured that the lock will get released. I'll take a look at the code when I have a chance and see what I can clever up. -- Matthew Caron Software Developer InsureMyTrip.com [EMAIL PROTECTED] (401) 773-9223 (401) 921-4530 fax ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mailmanager-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mailmanager-users
