Home/ Questions/Q 6031183
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T05:08:44+00:00

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

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0