>>Hi,
>>
>>One of the features of my ASP.NET application is where a user enters some information and on Submit a stored procedure is called, which adds record(s) to the database. Then a method is called which sends email(s) to a distribution list. Sometimes the Email method/routine takes quite a bit of time (up to a minute) and the user has to wait for the Acknowledgement of submit. Recently I read a couple of on-line articles on Task Parallel Library and on await and async. I am still not 100% sure I understand these concepts (but it never in the past stopped me from implementing things I don't understand :)). So I am thinking of converting the method that sends emails to the "await" and "async" type method so that the user will get to the acknowledgement page faster, while the emails are being sent on another thread.
>>
>>Does it make sense?
>
>Sure, that should work. The questions I'd have would be on how it would affect workflow.
>
>Right now, the user has to wait but gets a definitive answer back on when the e-mail process completed and (presumably) whether or not it was successful. This might be important if the user's next task depends on the current one being e-mailed successfully but it sounds like that's not the case for you.
>
>If you go async, and you still want to notify the user when a given e-mail is finished processing (successful or not), you may not be able to use your current notification technique because the user may be on some other page entering new data for the next request. Or, if they're still on the same page they might complete another e-mail request before the previous one finishes, so a single "e-mail status" section is ambiguous - does it show the status of the previous, or the most recent request?
>
>One way to get around that would be to have a section of the page that lists "recent e-mail submissions" (say, the most recent 5 or 10 or ?) This would show success or failure. Also it would not randomly interrupt or distract the user from the current task.
>
>If you don't care too much about success or failure you could just put up a brief message saying that the e-mail was submitted and not notify when it's complete. Or, you could have the e-mailing process log to a file, and let the user pull up recent entries from the log file if they want to know the results.

Current implementation of the program is that the user does indeed see a message if the email failed (nothing if email is successful). It says something like "Thank you for submitting the order. It was successfully created" and then in red "But the email notification has failed... please check blablabla"

And I am willing to skip (or consider it) the part of notifying the user of email success or failure in order to speed up his/her processing. Otherwise some complain that "they have to wait too long for the Acknowledgement message". But I am still debating (with myself) if not notifying the user of failed email will come back to bite me later.

Thank you for your input.