sendmail not part of a transaction
Not sure if this is a bug but I doubt it. If an exception occurs after a sendmail tag the mail is still sent. It should probably be part of a transaction.
"Jay, Dylan" wrote:
Not sure if this is a bug but I doubt it. If an exception occurs after a sendmail tag the mail is still sent. It should probably be part of a transaction.
Yes you're right, the sendmail tag sends the mail straight out. Queing and delaying delivery for the end of the transaciton however is asking for trouble, Zope's smtp code is fragile as it is, since it predates smtplib. I would check for all your error conditions first, and let the transport of mail be the very last option. Also this way you can tell if any of the 'important' stuff failed or not if the mail doesn't get delivered. not-all-side-effects-can-be-transacted-ly' yours, -Michel
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
Michel Pelletier wrote:
"Jay, Dylan" wrote:
Not sure if this is a bug but I doubt it. If an exception occurs after a sendmail tag the mail is still sent. It should probably be part of a transaction.
Yes you're right, the sendmail tag sends the mail straight out. Queing and delaying delivery for the end of the transaciton however is asking for trouble, Zope's smtp code is fragile as it is, since it predates smtplib.
I don't think that this would make things less stable. Besides, maybe whoever did this (probably not DC) could improve the SMTP logic at the same time. :) One disadvantage of defering sending mail is that you wouldn't be able to catch errors with the try tag. If someone wanted to work really hard, they could ad some logic to make a preliminary SMTP connection early to try to catch errors and a second one at commit time to actually send the mail.
I would check for all your error conditions first, and let the transport of mail be the very last option. Also this way you can tell if any of the 'important' stuff failed or not if the mail doesn't get delivered.
This is what they have to do now, but it is not ideal. Transactions *are* a really good idea and very helpful. I think if someone wanted to make the sendmail tag more transactional (or add a more transactional SMTP interface) it would be a good thing. Jim
"Jay, Dylan" wrote:
Not sure if this is a bug but I doubt it. If an exception occurs after a sendmail tag the mail is still sent. It should probably be part of a transaction.
Ideally, all operations should be transactional. This is difficult to achiev for external systems without transaction support. Still, pseudo-transactional behavior can be achieved by delaying external operations until transaction commits. I think this is a good idea, especially if the probability of failure of the external system is very low. Of course, if a failure occurs in the external system at commit time, it may not be possible to undo other operations. Similarly, it isn't possible to undo sending mail if an error occurs when commiting to other external systems. Still, delaying email delivery would at least prevent email delivery when there are application errors. This would be a fun project for soeone interested in learning more abut the transaction machinery. Jim
participants (3)
-
Jay, Dylan -
Jim Fulton -
Michel Pelletier