> But you did say you'd realized how.. "I realized earlier today how to" ;-)
Yes. I didn't say that the solution was general. :-) If you want an
atomic transaction, you have to put yourself in a position to have one.
Right now, that means we need to control a database transaction within a
mailet, and use that to create atomicity.
> I've pondered it for these past few days and been unable to see how one
> could guarantee that a mail was only processed, in the general situation
You can't do it without an enclosing transaction manager.
> Alternatives based on making internal lists won't help you unless the
> action of adding/removing or comparing mail with lists is atomic
> itself and atomic with the processing you are trying to control.
Exactly. :-) Even in a case where you use some GUID, you need to be able to
persist the effect of the mailet and the change to the GUID related status
in an atomic transaction.
As you said, in the case of the current "storm in a tea-cup", a database
solution can be constructed.
I don't know if we want to look at anything related to this for v3. We
would have to agree that mail *status* is always kept in a database, even
when mail content is stored in the file-system. I am amenable to that as a
discussion.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
