Noel, > I said that "the mailet has to be specially written to do it." What I > didn't say was how.
But you did say you'd realized how.. "I realized earlier today how to" ;-) 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, once if the processing takes a finite period. You would be compelled to assume either the start, or the end of processing was the gate which couldn't be passed twice, and these are the two options you would have to choose: 1/ gate is at the start, pass gate but processing is not completed, mail isn't re-processed and is "lost" 2/ gate is at the end, mail is processed successfully but terminated before it passes the gate, it is re-processed and "duplicated" 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. Of course in the specific case which started this discussion (aka. storm in a tea-cup) where database inserts are concerned this might be achieved through the use of 100% available database clusters and by the use of the mail-uid as a unique key in the database. In this situation duplication will fail because of duplicate values for a unique key, and db availability can be arranged to avoid any losses in all but the most extreme circumstances. (else banks wouldn't use them ;) d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
