How can I do an async retrieve of all the data in an entity using your repository ?

Apr 15, 2014 at 6:45 AM
Edited Apr 15, 2014 at 6:57 AM
I have seen the following:
        public virtual async Task<TEntity> FindAsync(params object[] keyValues)
            return await _dbSet.FindAsync(keyValues);
But if I don't have a specific value that I want then how can I do an async retrieve of all the data in an entity ?

I also notice you have this:
internal async Task<IEnumerable<TEntity>> SelectAsync(
In my IDE this gives a message with a green line under SelectAsync saying "This async method lacks await operators". Can you comment on this.

Apr 16, 2014 at 6:49 PM
We do not support Async to get all records at this time. The warning message you are getting is by design, you can ignore this for now.
Marked as answer by lelong37 on 4/16/2014 at 10:49 AM
May 11, 2014 at 6:14 AM
To retrieve async I changed this in EF6 Repository :

internal async Task<IEnumerable<TEntity>> SelectAsync(...) {
return await Task.Run(() => Select(query, orderBy, includes, page, pageSize).AsEnumerable()).ConfigureAwait(false);

by this :

internal Task<List<TEntity>> SelectAsync(...) {
return Select(query, orderBy, includes, page, pageSize).ToListAsync();

Do you think it's ok or not ?
Oct 14, 2015 at 6:56 AM
Hi Dragouf,

I've just added a comment about your async change in:

I think I'll copy Stephen Cleary's warning not to use it in ASP.NET, here too:

"There are (at least) four efficiency problems introduced as soon as you use await with Task.Run in ASP.NET:
•Extra (unnecessary) thread switching to the Task.Run thread pool thread. Similarly, when that thread finishes the request, it has to enter the request context (which is not an actual thread switch but does have overhead).
•Extra (unnecessary) garbage is created. Asynchronous programming is a tradeoff: you get increased responsiveness at the expense of higher memory usage. In this case, you end up creating more garbage for the asynchronous operations that is totally unnecessary.
•The ASP.NET thread pool heuristics are thrown off by Task.Run “unexpectedly” borrowing a thread pool thread. I don’t have a lot of experience here, but my gut instinct tells me that the heuristics should recover well if the unexpected task is really short and would not handle it as elegantly if the unexpected task lasts more than two seconds.
•ASP.NET is not able to terminate the request early, i.e., if the client disconnects or the request times out. In the synchronous case, ASP.NET knew the request thread and could abort it. In the asynchronous case, ASP.NET is not aware that the secondary thread pool thread is “for” that request. It is possible to fix this by using cancellation tokens, but that’s outside the scope of this blog post.