6

Consider an ASP.NET Web API 2 application, that provides fairly straightforward access to several DB tables using Entity Framework.

Which of the following options for object lifecycles would be best in terms of servicing the most concurrent requests?

  1. Instantiating a singleton DbContext to be used by all requests.
  2. Instantiating one DbContext for each incoming request.
  3. Instantiating one DbContext for each thread in the thread pool servicing incoming requests?
  4. Other?

Follow up question - What if I change the requirement to "requiring the least amount of DB server resources"? What would then be the best option?

urig
  • 16,016
  • 26
  • 115
  • 184
  • The clear best-practice is (2). Search for this topic and you'll find discussion. – usr Aug 24 '14 at 19:59
  • Thanks. Care to promote your comment to an answer with explanations? :) – urig Aug 25 '14 at 08:21
  • 1
    I'd rather not duplicate the existing information: http://stackoverflow.com/questions/10585478/one-dbcontext-per-web-request-why and https://www.google.com/webhp?complete=1&hl=en&gws_rd=ssl#complete=1&hl=en&q=lifecycle+DbContext+ASP.NET. – usr Aug 25 '14 at 08:26

2 Answers2

2

Based on a detailed reply to another question:

Options 1 and 3 in my question are completely invalid. The reason is that DbContext is not thread-safe and having multiple threads access will bring inconsistent data states and throw exceptions. Even in a "per thread" situation, ASP.NET Web API is likely to arbitrarily shift the handling of a single request between several threads.

Option 2 - Instantiating one DbContext for each incoming request - is the preferred way as it ensures only one thread at a time can access the DbContext.

urig
  • 16,016
  • 26
  • 115
  • 184
  • be careful how you interpret the answer. 1 and 3 are equally bad when you manage them as long running contexts. But if a request spawns several threads You may need 1 NEW context per thread. But No LONG running contexts. If you only use 1 new context per request and a request does Parallel tasks, the parallel threads might corrupt the context held in the main process. eg parallel search. I personally make sure I have 1 Short lived context per thread. So in the original question that would be option 2b ;-) – phil soady Aug 25 '14 at 15:41
0

Apart from not being thread safe, DbContexts should not be long lived. So you must use 2. (Or even one DbContext instance for each Db operation).

If your "fairly straightforward access to several DB tables" is really straightforward, I'd recommend you to use OData, and some advance js client, like breeze.js.

Please, see this sites:

  • ASP.NET Web API OData this exposes the data as a simple REST service
  • breeze.js this library provides advanced js functionality, similar to that offered by a DbContext, but on the browser side: syntax similar to LINQ, local (browser) data caching...

You can also consume the OData service directly (for example with jQuery AJAX) or with a simpler library (datajs, JayData)

JotaBe
  • 38,030
  • 8
  • 98
  • 117