CODEWITHSUNDEEP
c#entity-frameworkasp.net-coreasync-await
bruno_cw
bruno_cw

Reputation: 1031

Is it ever safe to not wait for SaveChangesAsync()?

Consider the following WebAPI method: 

[HttpPost]        
public async Task<IHttpResult> CreateWorkItem(Item wi)
{
    var item = await dataContext.Item.AddAsync(wi);
    await dataContext.SaveChangesAsync();
    return Ok();
}

Is there a situation where it would be safe not to await for a SaveChangesAsync() method?

In theory I would have a faster response time if I just sent a response while the flushing to database gets done in the background.

Is my assumption correct?

Upvotes: 1

Views: 1297

Answers (1)

Chris Pratt
Chris Pratt

Reputation: 239430

There's nothing magical about the await keyword. It quite literally means "wait on this task to complete before moving on". Tasks return hot, or already started, so whether you await them or not, the work is happening.

However, things can get dicey in situations where you don't wait for task completion. In particular, here, your context, which is required to actually do the save operation (remember that it owns the physical DB connection) is request-scoped. That means if you do not await the save and return from the action, you're now essentially in a race to see which completes the first: the save operation or the end of the request. If the end of the request (i.e. the final response is flushed to the client) occurs first, the context is disposed taking the active transaction and your SQL connection with it.

Another important reason to await is for proper exception handling. If you do not await, any exceptions thrown during the save will essentially be swallowed because the code has already moved on. That means you have no real assurances that the save actually completed successfully; all you've got is a wish and prayer.

With very rare exception, all async tasks should be awaited all the time. It doesn't always need to be in the same line (such as when using things like Task.WhenAll to await a series of tasks), but at some point or another the await keyword should be there. FWIW, those rare exceptions are mostly confined to desktop and mobile development where you often need to fire work off on new threads to prevent blocking the main, or UI, thread. That's not remotely a concern for web applications, so you can pretty much consider the "await all the things" rule universal in that context.

Upvotes: 6

Related Questions