[Zope] preventing transaction rollback

[Sean Hastings]

MailDropHost looks like the right immediate solution to this problem.
Thanks.

However, I would like to understand, and resolve the conflicts if possible -
Is there anyway to know if these are Read or Write Conflicts?

When I look in the event.log - I just see lines that say:

     INFO(0) ZODB conflict error at /the_folder/the_object/theFunction


Also, if I section off code as previously described, with
get_transaction().commit, and still see that it is executing multiple times,
does that mean that the code that is generating the conflict must be in that
sub transaction? or is it possible for more than one subtransaction to get
rolled back?

If I can pin down the source of these conflicts, I hope to be able to
eliminate or at least reduce them. Thank you very much for your help.

--Sean

> -----Original Message-----
> From: Tino Wildenhain [mailto:tino at wildenhain.de]
> Sent: Sunday, September 19, 2004 11:16 AM
> To: Jonathan Hobbs
> Cc: Sean Hastings; zope at zope.org
> Subject: Re: [Zope] preventing transaction rollback
>
>
> Hi,
>
> Am So, den 19.09.2004 schrieb Jonathan Hobbs um 14:55:
> > ...
>
> > >
> > > I thought that this try block with a commit() would isolate
> the send mail
> > > code in its own transaction, and then catch any conflict exception and
> > > ignore it. But I am still getting multiple emails per transaction when
> > > multiple requests happen at the same time and conflicts occur.
> >
> > An ugly solution:
> >
> > Create a variable (property field) on a temporary folder
> (contents stored in
> > memory).  When you send an email have the emailer routine load a unique
> > identifier into the variable. In subsequent emails, check the
> contents of
> > the variable before sending the email.
> >
> > As I said, 'ugly', but it should work!
>
> Sorry. No. It does not work. Temporary storage
> is bound to the same transaction machinerie
> as all other zope storages.
> This means your stored value is wiped out
> when a transaction rollback is done. (in case of
> a conflict error for example).
>
> MailDropHost should be a solution as Andreas
> said.
>
> Regards
> Tino
>