4

I have some questions regarding the entity framework context instance management.

My code base is composed of many independent components/agents all running in one process that can only do work by reading messages from their corresponding queues at their convenience(whenever the component is ready, it will pick up the next message from the queue so no concurrency issue at the component level)

Each of the components need to interact with the database independent from other components. I am wondering what is the better way to setup the context instance/s for each component. Here are some of the options

1> Have one instance of the the context used by all components. --> I think this is the worst as it creates many concurrency issues?

2> Give every component an independent instance of the context. --> This looks fine but

  • is it ok to have many context independent instances in one process while all components are running concurrently in this process?

  • should I create a new instance of context for every new message that the component will process or keep one context instance for the life of the component? I think the last one makes more sense but I am more used to use context in a using{} bracket and I am not sure if keeping one context live for the life of each component has any complications in the way I am using it?

  • can I rely on optimistic concrruency so that two different independent components won't put same record in the database given all contexts are in one process?

BTW, I am using entity framework 4.1.

iCode
  • 4,208
  • 9
  • 37
  • 74

1 Answers1

3

Definitely use one context per component / agent - if component is multithreaded use one context per thread. If each message processing is executed as separate "logical transaction" then use one context per message processing.

Why:

  • Context internally uses two very important design patterns - Identity map and Unit of work. This answer describes the behaviour enforced by these patterns.
  • Context and anything else in EF is not thread safe.

Optimistic concurrency doesn't mean that different contexts will not put the same record in the database. Optimistic concurrency means that update statements compare current state in the database with last known state by the context (there is a delay between loading record and saving new values and another context can change the record). If record changed you will get an exception and you must handle it somehow.

Community
  • 1
  • 1
Ladislav Mrnka
  • 349,807
  • 56
  • 643
  • 654
  • Thanks for your answer. If I use a context per messages, what's the cost of creating and destroying each context per message where I could have hundreds of messages to process per agent? Also, is there anything shared among two instances of my context in 4.1? Anything? – iCode Jun 13 '11 at 22:03
  • 1
    There should not be any significant overhead, even if there is overhead you don't have choice if you want your application to work correctly and use EF. All contexts internally shares description of model - building the model description is very costly operation and because of that it is built only once and shared among all context intances. – Ladislav Mrnka Jun 13 '11 at 22:12
  • Also, as for my scenario where I do NOT have any concurrency issue at an agent level(agent process messages one by one), what is the value of creating the context every time per message? I am now quite clear that the will be no issue doing so but still not clear what is the value of a new context per message instead of a context for the life of the agent given that there is not concurrency issue at agent level? In other words, what is the value of a new context per request ASIDE from concurrency issues? – iCode Jun 13 '11 at 22:36
  • The value can be for example reducing memory footprint. Context keeps internally reference to every entity it works with unless you manually detach every such entity. Also the value can be consistency of your application. If everything goes wrong with any message processing and you store anything in the context without saving changes next message will save this stuff as well. Moreover if you add to context anything which cause exception during saving your agent is dead, because without repairing data or recreating context you will not be able to save anything else. – Ladislav Mrnka Jun 13 '11 at 22:43
  • Very True! Thanks for your insights! – iCode Jun 14 '11 at 02:37