views:

223

answers:

3

There have been many question on managing EntityContext lifetime,

e.g. http://stackoverflow.com/questions/813457/instantiating-a-context-in-linq-to-entities

I've come to the conclusion that the entity context should be considered a unit-of-work and therefore not reused. Great.

But while doing some research for speeding up my database access, I ran into this blog post...

Improving Entity Framework Performance

The post argues that EFs poor performance compared to other frameworks is often due to the EntityConnection object being created each time a new EntityContext object is needed.

To test this I manually created a static EntityConnection in Global.asax.cs Application_Start().

I then converted all my context using statements to

using( MyObjContext currContext = new MyObjeContext(globalStaticEFConnection)
{
   ....
}

This seems to have sped things up a bit without any errors so far as far as I can tell.

But is this safe?

Does using a applicationwide static EntityConnection introduce race conditions?

Best regards, Kervin

+1  A: 
  • If your EF context is Application-wide, consider that user A has made changes (not committed) & user B has committed his changes, all changes will get committed to the database since both user A & B use the same instance

  • In my project, I did a per WebRequest intance of the EF context - ie. a context object is static from start through end of a web request & all operations in that request work with the same EF context. This has significantly speeded up my processing without the problem mentioned above.

One way to implement this is to use a DI container (I am using Unity) to manage the lifetime of the EF context. The per web request lifetime manager is not given out of the box in Unity, but there are tons of articles out there which show how this can be done.

HTH.

Sunny
Hi thanks, but my EntityContext is not application wide. The EntityConnection it uses is. I am using the EntityContext as a "unit of work", ie. a new context with each access basically.
kervin
+1  A: 

EntityConnection is documented to be not thread-safe. I think you could pool them, but you cannot use a single, static connection for a Web application, as there will be many threads involved.

Craig Stuntz
Thanks. I was certain it wouldnt be that easy, but I'm pretty much trying to figure out if anyone out there is pooling connections for performance. Since that MSDN blog post made quite a case for that.
kervin
I wouldn't change anything without retesting in .NET 4. This may already have been addressed.
Craig Stuntz