[Zope] get_transaction().commit() exceptions
Tim Peters
tim.peters at gmail.com
Thu Sep 2 18:16:25 EDT 2004
[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.
More information about the Zope
mailing list