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

    Question

  • Do I need to explicitly call Dispose() on DataContext object after use?

     

    Thanks

    Thursday, November 01, 2007 10:16 PM

Answers

  • 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.

    Thursday, November 01, 2007 11:46 PM
    Moderator

All replies

  • 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.

    Thursday, November 01, 2007 11:46 PM
    Moderator
  • 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!

    Friday, November 02, 2007 2:32 AM
  •  

    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

    Wednesday, December 26, 2007 9:08 PM
  • 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
    • Proposed as answer by TomTom1234 Monday, February 15, 2010 9:01 AM
    Tuesday, June 24, 2008 8:16 PM
  • 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
    Tuesday, July 28, 2009 4:35 PM
  • 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

    erm ... no. wrapping every DataContext in an using block kinda defeats the purpose of an O/R mapper in many ways.
    think of deferred execution and lazy loading for example.
    say you have customer table and an orders table with an foreign key between them. by wrapping your DataContext in an using block you effectively made it impossible for the O/R mapper to lazy load the orders if it was required, because the DataContext used to retrieve the customers has long been disposed of when you need the orders. which means you have to mess around with lots and lots of DataLoadOptions to make it working, or to disable lazy loading at all. which means you will load ANY related tables all time, no matter if they are required or not. epic fail.

    this is just one example of many where it doesn't make any sense to dispose something just because it implements IDisposable. IDisposable is a tool, no more no less. if your object doesn't hold any expensive resources like DB connections it just doesn't make any sense and you're better of to let the garbage collector do its job.
    Monday, February 15, 2010 9:12 AM
  • this is just one example of many where it doesn't make any sense to dispose something just because it implements IDisposable. IDisposable is a tool, no more no less. if your object doesn't hold any expensive resources like DB connections it just doesn't make any sense and you're better of to let the garbage collector do its job.

    I don't think there are such examples at all. Types should implement IDisposable only when necessary, and yes, you should always call Dispose on IDisposable instances. Just one reason why is that even if it's not really necessary now, future changes to that type can make calling Dispose critical (as their contract allows it).

    You should dispose DataContext in production environment. You don't need to wrap every call in using though, you should use some smarter context management techniques, e.g. per-request singletons in web applications. BTW, you have to do exactly the same with NHibernate session manager.

    Friday, July 23, 2010 8:52 AM
  • Hi.

    I have read this and another posts saying that it does not need to be disposed. After few months found connection leaks in my software and now I'm certainly sure that DataContext must be explicity disposed in some situations. Please try to use provided sample to make sure there are simple ways where NumberOfReclaimedConnections can grow resulting in limited connection pools exhausted (connection timeouts)

    http://social.msdn.microsoft.com/Forums/is/linqtosql/thread/34aebba2-d98e-4648-8472-bd730f1005ce


    Piotr Jaworski kk-electronic.com
    • Edited by pijaw Tuesday, March 01, 2011 1:36 PM english gramma corrections :-)
    Tuesday, March 01, 2011 1:35 PM
  • How would resources held by DataContext get cleaned up by the garbage collector when DataContext doesn't implement a finalizer to call Dispose? (Same with ObjectContext.)
    Wednesday, December 28, 2011 12:46 AM