3

I want to create a Singleton Object for Database context creation. I am just curious if it good practice to use singleton context in mvc applications.

Can somebody describe the pros and cons for a singleton context object?

melodiouscode
  • 2,105
  • 1
  • 20
  • 41
user1006544
  • 1,514
  • 2
  • 16
  • 26
  • @jamesakadamingo - Brother the time you have invested in correcting my grammatical errors , I am really impressed , rather than this if you have answered my query it will be more helpful I think. But ya thanks for pointing this Error, will keep in mind in future. – user1006544 Feb 24 '14 at 08:41
  • 1
    This question should not have been voted down in the first place. – Shashank Chaturvedi Feb 24 '14 at 09:06
  • @user1006544 not a deliberate act at editing your grammar! Just trying to help a user's question get answered when I don't have a moment to do it! – melodiouscode Feb 24 '14 at 10:28
  • Duplicate: http://stackoverflow.com/q/10585478/861716 – Gert Arnold Feb 24 '14 at 19:32
  • possible duplicate of [Who needs singletons?](http://stackoverflow.com/questions/4595964/who-needs-singletons) – Mike Feb 28 '14 at 00:35

3 Answers3

2

DbContext is not thread safe which is a massive con for its use as a singleton object in a multithreaded usage environment such as ASP.NET MVC. Multiple concurrent DB operations will result in a thrown exception and you would need to synchronize access to the singleton object to avoid such a scenario. You would also need to worry about stale cached data over its lifetime and manage refreshing said data appropriately.

Moho
  • 15,457
  • 1
  • 30
  • 31
  • 1
    This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. – web-tiki Feb 24 '14 at 08:15
  • 1
    This does answer the question, but I'll make it clearer – Moho Feb 24 '14 at 08:20
  • so it is not good to use singleton object , rather create new context every time for db interaction , is it correct? – user1006544 Feb 24 '14 at 08:45
  • not necessarily for every db interaction, but for a common thread of db interactions (in the case of ASP.NET MVC, that tends to be one context per request) – Moho Feb 24 '14 at 14:22
2

As a clarification point, consider if your singleton needs to be per session request or app domain. If you limit the scope to a single session request, you could be ok having a single access point (factory) for your variable creation and keep that value alive through that session, but make sure to dispose it when the request is complete.

However, don't keep a single context value alive for the entire app domain (static variable) or even user session. The context remembers every object that it fetched (to support tracking updated fields/values). Eventually you would end up duplicating your database in memory, but only with the values from that server instance. If you have a farm, this would be compounded by stale data between the servers over time.

Jim Wooley
  • 10,169
  • 1
  • 25
  • 43
0

It is really bad to use singleton DbContex. All changes will be check in each SaveChanges. When your DbContext have lived long enough, it will be verry slow.

maxlego
  • 4,864
  • 3
  • 31
  • 38