none
LinqSQL and memory 'leaks' RRS feed

  • Question

  • Woops, should have psoted here.

     

    Over on the Linq general forum I observed that I could n'tgo Delete(u)->Submit->Insert(u). It was observed that this is because the context is keeping hold of the 'deleted' items. Does anybody here know why?

     

    The follow on from the fact that it keeps 'hold' of the deleted items is that they obviously don't get collected, which can be demonstrated in a very simple program. Using the CLRProfiler I observe that all of the retained obejcts are allocated by the DataContext, sonethign to do with tracking.

     

    Is there some call I should be making on the DataContext to release all of these unreacheable objects?

     

    Code Snippet

    static void Main(string[] args)

    {

    DataClasses1DataContext db = new DataClasses1DataContext();

    var q = from p in db.Users where p.Name == "Dan" select p;

    for (int i = 0; i < 1000000; i++)

    {

    Console.WriteLine(String.Format("Iteration: {0}", i));

    if (q.Count() == 0)

    {

    for (int j = 0; j < 100000; j++)

    {

    User u = new User();

    u.ID = Guid.NewGuid();

    u.Name = "Dan";

    db.Users.InsertOnSubmit(u);

    }

    db.SubmitChanges();

    }

    db.Users.DeleteAllOnSubmit(q);

    db.SubmitChanges();

    }

    }

     

     

    Friday, July 4, 2008 12:54 PM

Answers

  • It's the DataContext's job to remember the references to all objects you've used with it.  Using a single DataContext to do extremely large number of inserts & deletes or query operations for an indeterminate period is not an appropriate use.  That said, the only way to 'free' up the references that the DataContext holds onto is to let go of the DataContext itself (or dispose it, which is effectively the same thing.) 

     

    If you really need to do a large number of unrelated operations via a DataContext you can create new DataContext instances per each operation or group them as necessary.  DataContext's are relatively cheap to create as long as you are using the same mapping source (which you are if you are using the DataContext code-generated by the designer.) 

     

     

     

    Friday, July 4, 2008 3:41 PM
    Moderator

All replies

  • It's the DataContext's job to remember the references to all objects you've used with it.  Using a single DataContext to do extremely large number of inserts & deletes or query operations for an indeterminate period is not an appropriate use.  That said, the only way to 'free' up the references that the DataContext holds onto is to let go of the DataContext itself (or dispose it, which is effectively the same thing.) 

     

    If you really need to do a large number of unrelated operations via a DataContext you can create new DataContext instances per each operation or group them as necessary.  DataContext's are relatively cheap to create as long as you are using the same mapping source (which you are if you are using the DataContext code-generated by the designer.) 

     

     

     

    Friday, July 4, 2008 3:41 PM
    Moderator
  • No, this is a leak.  It doesn't make sense to have to maintain several datacontexts because then you run into problems joining tables from different contexts.  You can't have the same table in two contexts in a namespace so it prohibits you from having multiple contexts for different tasks.  Why can't we just have a DataContext.RemoveUnreachable() or something like that?

     

    Disposing and recreating the context doesn't work because then you have to reload it's contents, there must be a better answer than "that's the way it is."

     

     

    Thanks,

    Steve Hatch

     

    Friday, July 11, 2008 10:25 PM
  • Has MSFT addressed this issue yet?  I have the exact same issue that Steve is having.  Does Entity Framework have the same behavior?

    Thank you,

    Wil Bloodworth
    Wednesday, August 19, 2009 9:01 PM
  • DataContext is designed to be a short-lived single unit-of-work as Matt says - if you follow this principle when designing your app then it shouldn't be a problem.

    [)amien
    Thursday, August 20, 2009 1:37 PM
    Moderator