Entity Framework 6 and Async

At a previous company that I worked for, one of my colleagues, Paul Czywczynski referred to Entity Framework as “Database Crack”. I can see where he was coming from. There is no substitute for a database developer who knows how to write a Common Table Expression. These days however, to be a well-rounded back-end developer, you’re a step ahead of the rest if you can write your own SQL code. Entity Framework is great for getting up and going quickly. The dynamic query generation is much better today than it was just a few years ago. Code-First has come a long way, especially with the introduction of Database Migrations.

The Task Parallel Library (TPL) is good. Async is great. Await is even better.

Recently, the EF team has brought asynchronous operations to the EF API. You now see extension methods for everything that executes a query; FirstOrDefaultAsync, SingleAsync, ToListAsync, etc… AWESOME right?

Not so fast…

Check this out, directly from the EF 6 Codeplex site:

For the moment, EF will detect if the developer attempts to execute two async operations at one time and throw.

Basically what this is saying, is that you cannot access the result of an async operation until you have awaited the previous. Doesn’t that effectively defeat the power and purpose of async operations in EF? I believe the problem at hand is that DbContext or ObjectContext is not thread safe. In other words, because EF manages change tracking behind the scenes, making it async is a no-no. If you change something on one thread, what happens to that object on the other thread? This is not a problem that I personally want to solve, but I hope that someone at Microsoft does. If they truly want to make the EF 6 API async, then they must tackle this as well.

These days, Microsoft is making their newer API’s task based. My advice to anyone reading this, is that if you are developing against the Microsoft stack, it would greatly benefit you to brush up on your async skills.

*** UPDATE ***

I filed a “bug” on the CodePlex site last week regarding this. Technically, it wasn’t a bug, but I wanted to see what they would say: CodePlex Entity Framework Work Item #1279


2 thoughts on “Entity Framework 6 and Async

  1. Jimmy Zimms

    Pretty late but in answer to your question: “Doesn’t that effectively defeat the power and purpose of async operations in EF? ”

    No. The purpose of using tasks here is not parallelism but to prevent thread blocking (which is a huge nono in throughput – USUALLY [YMMV]). Basically underneath at the low level IO completion ports get used so the thread in question can be freed and, depending on your scheduler, potentially reused during that whole period where the network call to actually send and run the query, which in OS time is LONGGGGG, until there’s an actual result to process. Threads cost a huge amount resources, relatively, and are not infinite. The ability to write what looks like synchronous code that leverages IO asynchronicity, thus avoiding the hard to follow APM, is the value proposition. In fact, in just about all OSs (and every version of Windows), there’s no such thing as “blocking IO” and any higher level APIs that exhibit that are actually “faking it”.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s