I understand the issues here. The point that I was trying to make was that it is actually not possible to absolutely guarantee "once and only once". There will always be a window, however small, for either a loss or a duplicate (in the case of JAMES, a duplicate).
JAMES currently takes all reasonable measures toward "once and only once". Hunting for an absolute guarantee (even if it were possible) would not really make JAMES any more useful to 99.9% of users.
Cheers
ADK
Noel J. Bergman wrote:
Aaron, There are distributed transaction managers. Moot point in this context.Let's consider a simple example. Let's say that James accepts a message and the sender's connection is pulled at just the wrong point. James has spooled the message, but the sender can't get the notification. RFC 1123 states that 'When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously, i.e., it MUST NOT lose the message for frivolous reasons, e.g., because the host later crashes or because of a predictable resource shortage.' Therefore, James may see that the sender's connection has gone bye-bye, but that doesn't mean James should not send the message. Meanwhile, the sender doesn't know if the message was sucessfully sent. RFC 1123 (amongst others) states that the sender "MUST be able to [retry] until a delivery attempt succeeds." Sending e-mail is not a database transaction. James tries to be as reliable as possible. James should not send the "250" until after the message is in the spool. To do otherwise would be a defect requiring a fix. Once the message is in the spool, it stays there until after a sucessful transfer elsewhere. If you need guaranteed delivery over SMTP, you could have the destination send an ACK after it has successfully processed the message. The sender continues to periodically resend the message until receiving the ACK. The receiver must discard duplicates.It may be possible to track the progress of a mail through the processorAs you noted, this would require making a database update for each transition between mailets. There is a different solution, available today. Configure a separate processor element for each non-idempotent operation. That way there will be a spooler transition recording the change where it is necessary. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
