Data Platform Developer Center > Data Platform Development Forums > ADO.NET Entity Framework and LINQ to Entities > Do I need to explicitly call Dispose() on DataContext object?
Ask a questionAsk a question
 

AnswerDo I need to explicitly call Dispose() on DataContext object?

Answers

  • Thursday, November 01, 2007 11:46 PMMichael Pizzo - MSFTModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    The short answer; no, you don't have to, but you should...

     

    DataContext holds state (for example, a SqlConnection and pointers to the objects you have retrieved). These will eventually get cleaned up by the GC once you release all references, but some of these objects (for example, the underlying SqlConnection) may be holding resources that you typically want to release as soon as your are finished, rather than relying on the GC to clean up.

     

    We generally recommend constructing a DataContext (and ObjectContext in the Entity Framework) within a using statement to make sure that resources are cleaned up when you leave the block.  For example, in C# we would recommend:

     

    using(NorthwindDataContext db = new NorthwindDataContext())

    {

    //do stuff with DataContext

     

    } // Dispose is called on DataContext when you leave the using block

     

    This is the same pattern we recommend for using DbConnections in ADO.NET 2.0.

All Replies

  • Thursday, November 01, 2007 11:46 PMMichael Pizzo - MSFTModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    The short answer; no, you don't have to, but you should...

     

    DataContext holds state (for example, a SqlConnection and pointers to the objects you have retrieved). These will eventually get cleaned up by the GC once you release all references, but some of these objects (for example, the underlying SqlConnection) may be holding resources that you typically want to release as soon as your are finished, rather than relying on the GC to clean up.

     

    We generally recommend constructing a DataContext (and ObjectContext in the Entity Framework) within a using statement to make sure that resources are cleaned up when you leave the block.  For example, in C# we would recommend:

     

    using(NorthwindDataContext db = new NorthwindDataContext())

    {

    //do stuff with DataContext

     

    } // Dispose is called on DataContext when you leave the using block

     

    This is the same pattern we recommend for using DbConnections in ADO.NET 2.0.

  • Friday, November 02, 2007 2:32 AMJulie LermanMVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    This is a great reminder for both LINQ to SQL and EF. THanks for the clarification Mike. Now I'm going to go back and re-read the "managing connections" section of the ef docs!

  • Wednesday, December 26, 2007 9:08 PMJohn Rusk Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

     

    Michael,

     

    I thought that DataContext did not actually hold a connection open.  That instead it just opened it, used it, and closed it.  Is that true?  If so, where does not need to "dispose" it come from? 

     

    Does it hold other unmanaged resources too?

     

    John

  • Tuesday, June 24, 2008 8:16 PMecard_guy Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    JohnR, you are correct DataContext objects do not hold connections or expensive resource open.

    Michael P, it is not correct that DataContext objects hold DB connections or other expensive resources.

    In fact, it is not critical to call Dispose on a DataContext.

    It's easy to prove this:

    Create a simple text page that does NOT dispose a datacontext, and run a high load against it on a test machine.  Use perfmon and you'll see the difference between dispose and not dispose is negligable.  Scalability is still as linear as could be.

    There is a little more explanation of this subject here:
    http://lee.hdgreetings.com/2008/06/linq-datacontex.html

    Regards,
    LTG
  • Tuesday, July 28, 2009 4:35 PMblogbybob Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I would think we would aim to code to the interface and not the implementation. If it inherits from IDisposable, we should be disposing it.

    Regards,
    Bob