Hi, sendEmailDated is scheduled by default to wake up every 15 minutes. I got into situation, that the service woke up, and previous exceution did not finish, hence the file was collected again, what ended out in infinite email sending (i was sending mail to 5000 customers, and it took more than 15 minutes, and each time it was recognized as event that need to be sent).
i think the following mechanisms need to be implemented, in order to avoid the communication events to be picked more than once, and in order to make sure, that mail will not be sent twice. 1) adding another state to communicationEvnet, that symbolize that records the message send is being picked up (as of now, the service is picking up In-Progress and change it to Complete when ending), i suggest to add the status "sending", so when the sendEmailDated wakes up, before it starts sending, its taking ownership for it, and the next instance that wakes up, will not pick the communication event. 2) i think that the suggestion i described in #1, is still not good enough, and there should be record level mechanism to avoid multiple sending of same message (e.g. in case the service crushes, and being reexcuted, need to still not send same email twice). The current mechanism, uses same transaction for all the mail that need to be sent. i sugget the following mechanism instead: making new transaction for every individual mail send. the transaction will call the following: create unique constraint on CommunicationEvent for the combination of parentCommEventId and contactMechIdTo. when sending individual message, - create the individual communication event (for each and every recepient,): if its already there, rollback the transaction (this means that the mail already been sent): this will avoid continue send mail in case it was already sent - send the email if there is a problem with sending the mail, rollback the transaction, and then the individual communication event will not be created in this case, we can ensure that the mail will never be sent twice. Comments will be appreciated. Thanks, Amit
