c# working with Entity Framework in a multi threaded server

Asked 23/2, 2012 at 15:26 Answered 17/2, 2016 at 1:7

Solved c#database multithreading entity-framework objectcontext

What is the best practice for working with entity framework in a multi threaded server? I'm using entity framework ObjectContext to manage all my database actions, now I know this context isn't thread safe, so for now when I need to use it to perform some db actions I surround it with lock statement to be safe. Is this how I should do it??

Reindeer answered 23/2, 2012 at 15:26 Comment(0)

Some quick advices for Entity Framework in a multi-threaded environment:

Don't use a unique context with locks (no singleton pattern)
Provide stateless services (you need to instantiate and dispose one context per request)
Shorten the context lifetime as much as possible
Do implement a concurrency-control system. Optimistic concurrency can be easily implemented with Entity Framework (how-to). This will ensure you don't overwrite changes in the DB when you use an entity that is not up-to-date

I'm a bit confused, I thought that using one context is good because it does some catching I believe, so when I'm dealing with the same entity in consecutive requests it be much faster to use the same context then creating a new context every time. So why does it good to use it like this if It slower and still not thread safe?

You could use only one context, but it's strongly discouraged unless you really know what you are doing.

I see two main problems that often happen with such an approach:

you'll use a lot of memory as your context will never be disposed and all manipulated entities will be cached in memory (each entity that appears in the result of a query is cached).
you'll face lots of concurrency issues if you modify you data from another program/context. For example, if you modify something directly in your database and the associated entity was already cached in your unique context object, then your context won't ever know about the modification that was made directly in the database. You'll work with a cached entity that is not up-to-date, and trust me, it'll lead to hard-to-find-and-fix issues.

Also don't worry about performances of using multiple contexts: the overhead of creating/disposing a new context per request is almost insignificant in 90% of use cases. Remember that creating a new context does not necessarily create a new connection to the database (as the database generally uses a connection pool).

Harper answered 23/2, 2012 at 15:42 Comment(7)

If I create a context per request (or per db work) and I have more then one context changing a specific object from the db at the same time, is this a problem? – Reindeer 23/2, 2012 at 18:13

@Reindeer You'll typically have concurrency issues. Trying to update the same entity by multiple threads at the same time will be hard to implement without concessions. – Harper 23/2, 2012 at 18:14

I'm a bit confused, I thought that using one context is good because it does some catching I believe, so when I'm dealing with the same entity in consecutive requests it be much faster to use the same context then creating a new context every time. So why does it good to use it like this if It slower and still not thread safe? – Reindeer 23/2, 2012 at 18:35

Thanks, I understand the advantage of creating a context per work, then if I understand right my only concern is the concurrency issue, and this I can't really solve but to catch the exceptions and deal with them? – Reindeer 27/2, 2012 at 15:3

@Reindeer Yes. The most simple way to deal with concurrency (CRUD ops) is to display a message to the user saying that the object has been modified by someone else and must be reloaded. It should be OK in 90% of cases. If you don't want to display such a message, then you could manually resolve concurrency conflicts: if you want to save to the DB an entity, and the entity currently stored in the DB is more up-to-date than the entity you want to save, then you'll have to manually select which properties you want to use from the DB entity and which properties you want to use from the entity to save. – Harper 27/2, 2012 at 15:45

Thanks for the great explanation. Was having unexplained failures of my connection to the database, and it turned out to be the fact that I was using a static ObjectContext. This was really helpful. – Caracaraballo 18/12, 2012 at 13:13

Doesn't having a perrequest context cause performance issues? since DbContext is a memory consuming entity – Bilbrey 15/5, 2016 at 10:49

Is this how I should do it??

No. At a minimum, use a context per thread but I strongly encourage you to think of a context as unit of work, and thus use a context per unit of work per thread.

It's up to you to define "unit of work" for your application. But don't use lock to use a context across multiple threads. It doesn't scale.

Shirleeshirleen answered 23/2, 2012 at 15:37 Comment(3)

This. One additional point - the resources that you're trying to conserve, theoretically, are already conserved by connection pooling. – Renarenado 23/2, 2012 at 15:44

Do u mean that I need to create a context before every db work and dispose it after the work is done? For example when client send login request, server will create a context-> check username&password in the DB with this context-> dispose the context – Reindeer 23/2, 2012 at 18:5

OK thanks so ill use one context per work, still I'm trying to understand how to deal with the scenario where more then one context is changing a specific entity at the same time... – Reindeer 26/2, 2012 at 13:1

You are treating ObjectContext like it is an extremely expensive entity, so you are instantiating once and then treating it as a "facade". There is no need to do this. If, for no other reason, the connections are pooled underneath the hood and cost very little (microsecond? - probably less?) to completely set up the "chain of objects" to use the ObjectContext abstraction.

The ObjectContext, much like direct use of SqlConnection, etc., is designed to be used with an "instantiate as late a possible and dump as soon as possible" methodology.

EF gives you some safety in that you have the ability to test whether you have the latest objects prior to committing (Optimistic Concurrency). This does not mean "thread safe", per se, but it accomplishes the same thing if you respect the rules.

Dichroscope answered 23/2, 2012 at 15:44 Comment(0)

Typically the ObjectContext shouldn't be used globally throughout the application. You should create new ObjectContexts frequently and dispose old ones. They certainly aren't threadsafe either. If you continue to use the same ObjectContext (depending on the lifetime of your application) it is easy to get an out of memory exception if you modify massive amounts of data since references to entities that you change are held by the object context.

Autotransformer answered 23/2, 2012 at 15:44 Comment(0)

I create a new Context for each atomic operation and dispose the context. As far as i know from books and articles, i prefer to keep life time of Context as short as possible. (but it depend on you approach and you application type, winform or web)

Please find more information at great article. http://www.west-wind.com/weblog/posts/2008/Feb/05/Linq-to-SQL-DataContext-Lifetime-Management

Good books: http://books.google.co.th/books?id=Io7hHlVN3qQC&pg=PA580&lpg=PA580&dq=DbContext+lifetime+for+desktop+application&source=bl&ots=ogCOomQwEE&sig=At3G1Y6AbbJH7OHxgm-ZvJo0Yt8&hl=th&ei=rSlzTrjAIovOrQeD2LCuCg&sa=X&oi=book_result&ct=result&resnum=2&ved=0CCgQ6AEwAQ#v=onepage&q&f=false

Existing discussion at Datacontext Lifetime in WinForm Binding Scenario

Leifleifer answered 23/2, 2012 at 15:43 Comment(0)

I use entity framework in a multi-threaded environment, where any thread, ui and background (both STA and MTA), can concurrently update the same database. I resolved this problem by re-creating the entity connection from scratch at the start of usage on any new background thread. Examining the entity connection instance ConnectionString shows a reader guid which I assume is used to link common connection instances. By recreating the entity connection from scratch the guid values are different for each thread and no conflict appears to occur. Note the assembly is only required to be the same assembly as the model resides.

public static EntityConnection GetEntityConnection(
// Build the connection string.

  var sqlBuilder = new SqlConnectionStringBuilder();
  sqlBuilder.DataSource = serverName;
  sqlBuilder.InitialCatalog = databaseName;
  sqlBuilder.MultipleActiveResultSets = true;
  ...
  var providerString = sqlBuilder.ToString();
  var sqlConnection = new SqlConnection(providerString);

// Build the emtity connection.

  Assembly metadataAssembly = Assembly.GetExecutingAssembly();
  Assembly[] metadataAssemblies = { metadataAssembly };
  var metadataBase = @"res://*/{0}.csdl|res://*/{0}.ssdl|res://*/{0}.msl";
  var dbModelMetadata = String.Format(metadataBase, objectContextTypeModelName);
  // eg: "res://*/Models.MyDatabaseModel.csdl|res://*/Models.MyDatabaseModel.ssdl|res://*/Models.MyDatabaseModel.msl"
  var modelMetadataPaths = modelMetadata.Split('|');
  var metadataWorkspace = new MetadataWorkspace(modelMetadataPaths, metadataAssemblies);
  var entityDbConnection = new EntityConnection(metadataWorkspace, sqlConnection);
  return entityDbConnection;

Mckie answered 17/2, 2016 at 1:7 Comment(0)

Recommended topics

Hot tags