如何发送电子邮件和回滚更改？

Question

I am creating a complaint registration form for user in asp.net MVC . The complaint is send to user email address and complaint is save into SQL server 2017 database. I need a suggestion. my question is, How do I handle email and database?

condition 1 - what if database fails to save data but email is sending.
condition 2 - what if database save data to table but fails to send email.

How I did,

public void MyFunction()
{
    try {
       var db = DbContext();
       //some code
       //The number of state entries written to database
       int entities = db.SaveChanges();
       if (entities > 0)
       {
          SendEmail();//what fails to send email and complaint is created. 
       }
    }
    catch(Exception ex)
    {
        //exception is handle
    }
}

When db.SaveChanges() is done, it return how many tables are written to database. From my homework, Second condition is most important.

The Result I want is, both process of creation and sending email is handle smoothly.

Is I am on right path or not?

Any suggestion is appreciated.

Answer 1

What I would do in this case is have the emails saved to a table in the database, and implement a service that reads from that table and sends any unsent emails with a retry count for each entry.

That way you can retry sending the email at any time if it fails.

Answer 2

In real life you'll try to handle the email processes to another service (like sendgrind), so your application will store a request to send an email after the save is done. This request will be handle by your service whenever it can; Also, you won't need to be awaiting for the email to be sent in order to finish the user's request.

Since you're doing a homework you can:

1- [Recommended] store that email in a table and have a small service reading from it, once it found a record, send an email and flagged as done .

2- [Not Fancy] Do it exactly as you are doing it. Save the record and if success send an email.

Answer 3

This is an interesting problem because it asks you to consider trade-offs, probabilities, and perfection vs. what's good enough.

Here's what's good enough: Update the database. If it succeeds, put a message in a queue (which could be another database table) that will result in an email being sent.

You could just send the email directly via SMTP right when the database gets updated, but there's a small chance that due to some odd transient condition the email wouldn't get sent. (That happens - maybe SMTP permissions get messed up and the email gets rejected.) Putting it in a queue with a separate process is a reasonable approach to make sure there's some resilience for your emails.

Why is that only "good enough?" Because nothing is bulletproof. It's still possible that your email might not get sent. After all, we're concerned that the database update might fail. But if we're sending the email by inserting a record into another database that some other process monitors, doesn't that mean that could fail too? What will we do if the first database update succeeds but the one to send the email fails?

That's where we start making trade-offs. It's possible that we might insert a complaint into the database but not send an email. How likely is that, and if it happens, how bad is it? And whatever we might consider doing in response to that unlikely scenario, couldn't that fail too?

That's a rabbit hole. We can endlessly make our code more and more complex trying to account for less and less likely scenarios, but it's not worth it. Eventually bugs in our overly complex code will become the reasons why something doesn't work.

Instead of chasing after that, it makes more sense to realize that sometimes our code will fail because of things we can't control, and to know what that failure will look like. Again, this is a question of what's good enough.

• The initial database update fails. The user sees a message saying that their complaint was not saved. Perhaps we can provide them another way to contact us. The exception gets logged so that we can figure out what happened.
• The initial database update succeeds, then we send the email message to a queue. The email process fails. That should also get logged. That might be more urgent, because if one email fails, perhaps lots of them are. Hopefully that process provides some sort of alert if it's down so someone can fix the problem.
• The initial database update fails, and trying to send the email message to the queue fails. We log that. Again, hopefully there's something to let us know when stuff is failing, even if it's an email digest that someone gets.

Even that can fail. Our logging and our alerts can fail. We can replace them with something more resilient, like a better message queue. But we could drive ourselves insane trying to account for everything when it's impossible. All we can do is try to make our applications reliable and resilient.