Tim Edwards wrote:

A seperate thread checks the email server and saves new tickets (emails) to the ZODB. This mail-checking thread somtimes gets ConflictError at the call to get_transaction().commit(). This exception goes unhandled and the mail-checking thread dies. This means that the product will still work - it just won't retreive any email messages.

Is it a good idea to try and catch this exception?

Yes, but only if you know what you're doing ;-)

If so what should we do with it? will catching it stop the mail-checking thread from dying?

Yes, but you need to be careful what you do with it. It requries an understanding of what that exception means and how to safely recover from it. Please ask on zodb-dev@zope.org where people with more knowledge than I can help out... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

[Tim Edwards]

We are using MailManager from logicalware (http://mailmanager.sourceforge.net/). This application stores its data as objects in the ZODB.

A seperate thread checks the email server and saves new tickets (emails) to the ZODB. This mail-checking thread somtimes gets ConflictError at the call to get_transaction().commit(). This exception goes unhandled and the mail-checking thread dies. This means that the product will still work - it just won't retreive any email messages.

Is it a good idea to try and catch this exception? If so what should we do with it? will catching it stop the mail-checking thread from dying?

As Dieter said, the usual dance is to catch, abort, and try again. Conflict errors are expected at times when using ZODB. Its approach to concurrency is "optimistic": it doesn't lock objects. As many transactions as you like can hammer away at once, and ZODB raises ConflictError at commit time if multiple transactions tried to change the same object simultaneously. The expected response is for the app to abort the transaction, and try it again. Unless there are "hot spots" (objects frequently changed by multiple transactions simultaneously), this is an effective approach (safe and fast). Catching the exception will definitely stop the thread from dying, BTW. Dying is a direct consequence of an uncaught exception. In the limit, you'll probably want to put everything your thread does in an outermost try/except structure, log all exceptions that occur, but keep going no matter what.