dtml-sendmail and transactions: Request For Comments
A new fishbowl proposal http://dev.zope.org/Wikis/DevSite/Proposals/TransactionalEmail Zope's dtml-sendmail tag is not integrated into the transaction system. This leads to two problems: o Duplicate copies of each email will be sent if a request has to be retried due to a conflict error. o Emails can be sent even if a request never completes, due to an error rendering the tail of the page, or a problem detected at transaction commit. Any comments gratefully accepted. Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson writes:
A new fishbowl proposal
http://dev.zope.org/Wikis/DevSite/Proposals/TransactionalEmail
Zope's dtml-sendmail tag is not integrated into the transaction system. This leads to two problems:
o Duplicate copies of each email will be sent if a request has to be retried due to a conflict error.
o Emails can be sent even if a request never completes, due to an error rendering the tail of the page, or a problem detected at transaction commit.
Any comments gratefully accepted. Good, but isn't it difficult to make mail sending transactional:
The sending may raise exceptions. Zope is very angry to get exceptions during the second phase of the two-phase commit. This means, sending must go into the first phase. But in this case, they are sent even if a different transaction manager rejects the "commit" request (or raises an exception). Dieter
At 10:43 PM 8/10/01 +0200, Dieter Maurer wrote:
Good, but isn't it difficult to make mail sending transactional:
The sending may raise exceptions.
Zope is very angry to get exceptions during the second phase of the two-phase commit.
This means, sending must go into the first phase. But in this case, they are sent even if a different transaction manager rejects the "commit" request (or raises an exception).
The way Ty and I handle this in our applications is to not use the sendmail tag, but instead write a file to a queue directory, where it is then sent by another process which monitors the queue. This is easier to make transactional, since the commit operation only has to move the file to commit it. Unfortunately, this is not a general solution for Zope, since it then requires the existence of that other process. But in theory one could create a Product that would implement a daemonic thread for sending queued mail in this fashion.
On Fri, 10 Aug 2001 22:43:59 +0200 (CEST), Dieter Maurer <dieter@handshake.de> wrote:
Good, but isn't it difficult to make mail sending transactional:
The sending may raise exceptions.
Zope is very angry to get exceptions during the second phase of the two-phase commit.
http://dev.zope.org/Wikis/DevSite/Proposals/TransactionalEmail outlines how I plan to minimize this risk. 99% of the sending work is done during the rendering of the dtml-sendmail tag; it does everything up to sending the final "." which indicates the end of the message body. This allows the most common errors to be detected in the same place as today. These errors include: 1. failure to connect 2. server configuration prevents email relaying 3. destination address wrong (for some types of wrong)
This means, sending must go into the first phase. But in this case, they are sent even if a different transaction manager rejects the "commit" request (or raises an exception).
I plan to send the final "." in the second phase, only after all other transactional components have agreed that the transaction should complete. At this point there is very little that can go wrong: the mail server running out of disk space is top of the list. I plan to convert any exceptions into log messages (because, as you say, Zope would be angry for me to let the exception escape). I dont see this as a major problem in most cases. (unless we are too far out of disk space to store the log message too ;-( On Sat, 11 Aug 2001 12:29:32 -0500, "Phillip J. Eby" <pje@telecommunity.com> wrote:
The way Ty and I handle this in our applications is to not use the sendmail tag, but instead write a file to a queue directory, where it is then sent by another process which monitors the queue. This is easier to make transactional, since the commit operation only has to move the file to commit it.
Unfortunately, this is not a general solution for Zope, since it then requires the existence of that other process. But in theory one could create a Product that would implement a daemonic thread for sending queued mail in this fashion.
It would be nice if this other process could deliver mail directly to its recipients, without having to go via another mailer process. An alternative way of looking at the problem; it would be nice if sendmail could grow a two-phase commit extension. Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson writes:
... I plan to send the final "." in the second phase, only after all other transactional components have agreed that the transaction should complete.
At this point there is very little that can go wrong: the mail server running out of disk space is top of the list. I plan to convert any exceptions into log messages (because, as you say, Zope would be angry for me to let the exception escape). Sounds good!
Dieter
participants (3)
-
Dieter Maurer -
Phillip J. Eby -
Toby Dickenson