6

I have a few long running tasks on my server. Basically they are like scheduled tasks - they run from time to time.

They all required access to the DB and I use Entity Framework for that. Each task uses a DbContext for access.

Should the DbContext object be recreated on every run or should I reuse it?

Daron V
  • 197
  • 2
  • 8
  • Related (if not duplicate...) question: http://stackoverflow.com/questions/15148074/exploring-the-pitfallsif-any-of-having-a-dbcontext-for-each-viewmodel-class-th?rq=1 – nemesv Sep 22 '13 at 19:42

2 Answers2

7

I should say "it depends" as there are probably scenarios where both answers are valid, however the most reasonable answer is "the context should be disposed as soon as it is not needed" which in practice means "dispose rather sooner than later".

The risk that comes from such answer is that newcomers sometimes conclude that the context should be disposed as otfen as possible which sometimes lead to a code I review where there are consecutive "usings" that create a context, use it for one or two operations, dispose and then another context comes up next line. This is of course not recommended also.

In case of web apps, the natural lifecycle is connected with a lifecycle of web requests. In case of system services / other long running applications one of lifecycle strategies is "per business process instance" / "per usecase instance" where business processing / use case implementations define natural borders where separate instances of contexts make sense.

Wiktor Zychla
  • 47,367
  • 6
  • 74
  • 106
1

Yes, DbContext should only live for a very short time. It is effectively your unit of work

You should definitely create it each time you're going to use it. (Well, you should inject it but that's another discussion :-))

Update : OK, I accept that 'create it each time you're going to use it' could be misleading. I'm so used to context being an instance on a class that is injected and so lives only for the life of a request that I struggle to think of it any other way... @wiktor's answer is definitely better as it more correctly expresses the idea that you should "dispose sooner rather than later"

Paul D'Ambra
  • 7,629
  • 3
  • 51
  • 96
  • This is not true (and parts of your answer contradicts each other). Since context is a unit of work implementation, it should live as long, as it needed for completion of that unit of work. In real applications, this can be rather long time. – Dennis Sep 22 '13 at 19:54
  • The whole thing is not true, @Dennis, or just the part you mention? Define a long time... – Paul D'Ambra Sep 22 '13 at 19:56
  • 1
    Minutes, hours... There can be very different units of work. If those units related with some data access, it often suitable to create context, when the work had started (e.g., user had started to edit some document), and dispose it, when the work had finished (user had pressed "Save" button). – Dennis Sep 22 '13 at 20:02
  • so you recommend hold a DBContext for minutes or hours so that a user can edit some data - crikey! – Paul D'Ambra Sep 22 '13 at 20:09
  • I can't see any recommendations in my comments. The only thing I'm trying to explain, that there could not be precise recommendations, when to dispose context, because there are many usage scenarios. The only thing, that could be a reference point, is a unit of work duration. – Dennis Sep 23 '13 at 07:29