EF 6: Async
this post is the first in a series about what’s new in EF 6.
great improvements are about to come with Entity Framework 6.
it is a major release and the first one since EF become an open source.
each post in the series will be dedicate to a single feature.
this post will focus on a new EF a-sync features.
the first question that should be asked is, why do we need parallel data access?
moreover why do we need a dedicate parallel data access API, rather then using the TPL Task.Run(…) in order to introduce parallelism?
the answer is related both to thread safety and ThreadPool optimization.
a dedicate data access API for parallel programming, ensured a thread safe access, which may not be a trivial task.
furthermore, when the database is executing a query the .NET thread is idle (waiting for the execution result).
if this idle thread has taken from ThreadPool (either directly or through high level API like TPL Task.Run(…)) it could lead to a ThreadPool starvation.
assuming that you have a 2 second query, Task.Run(…) will hold the ThreadPool’s thread for 2 second even though it idle while the database is executing the query.
what you really want is an API that operate over IOCP (IO completion port). IOCP API will release the ThreadPool’s thread back to the pool and re-claim a thread at the completion time.
at the API level you can find a-sync operations everywhere.
I will present some of the main API.
the following snippets, will use the following entities (code first):
and the following context:
notice the await at line 4.
line 5, is where the magic happens.
EF 6 is having a great parallel API, which respect IOCP and compatible with the new async / await syntax.