Comments on: Disposing list’s SPSite/SPWeb without ParentWeb

By: Keith Dahlby

Keith Dahlby — Sat, 01 Nov 2008 16:34:39 +0000

You’ve discovered the fundamental issue with the current implementation of Dispose(): The objects are closed and marked as invalid, but they still work. However, behavior of an IDisposable after it has been disposed is technically undefined. While the code might seem to work 99% of the time, there is absolutely no guarantee that it will always work.

Regarding returning an SPListItem or SPFile, I think you have to assume they might need a reference to their parent Web at any time. So you should either extract the data you need into a non-SP object (DataTable, custom business object, anonymous type in 3.5), or find a way to Dispose later. Ultimately, you should only dispose if you’re 100% certain the reference will never be used again.

By: Andrew Challen

Andrew Challen — Sat, 01 Nov 2008 09:44:08 +0000

What I’m still struggling to get my head round is that even if you move the
webToDispose.Dispose();
webToDispose.Site.Dispose();
to inside the getList method; when the foreach on the returned SPList doesn’t fail. What’s more is that if I compare the hash code before my premature dispose and after the for each they are the same, why? I have a few ideas but don’t know how to find out which is right yet.

Secondly if I return a SPListItem or SPListItem.File etc. do I still need to dispose of the SPSite and SPWeb only after I’ve used them?

By: Keith Dahlby

Keith Dahlby — Fri, 31 Oct 2008 14:14:41 +0000

I agree that this approach isn’t pretty, it was just one of my first investigations into this issue. I prefer the pattern described in my post “SPSite/SPWeb Leaks Revisited”, though the initial example is still rather contrived. Ultimately there are several correct solutions, depending on what you need from the objects in question. Just be careful returning any SharePoint object from a function in which its parent web (or site) has been disposed. If you’re caching a DataTable as recommended, you shouldn’t have much to worry about.

By: Andrew Challen

Andrew Challen — Fri, 31 Oct 2008 12:15:02 +0000

I’d not tired executing it! My feeling is that
private SPList getList(out SPWeb webToDispose)
is dangerous though as you need to remember to know what to do with webToDispose perhaps out
I think I’d rather see
private SPList getList(out object[] objectsToDispose)
I’m still thinking that I’d rather see neither
For my task I’m going to try using similar idea to the CacheData function here
http://msdn.microsoft.com/en-us/library/bb687949.aspx

By: Keith Dahlby

Keith Dahlby — Thu, 30 Oct 2008 17:51:27 +0000

The site is disposed at the end of DoSomething():

if (webToDispose != null) {
webToDispose.Dispose();
webToDispose.Site.Dispose(); // <–
}

The site can’t be disposed within getList because disposing an SPSite also disposes all webs opened from it, including the web we need to leave open.

By: Andrew Challen

Andrew Challen — Thu, 30 Oct 2008 17:07:30 +0000

SPSite site = new SPSite(“http://solutionizing.net”);

shouldn’t you dispose the site too?

i.e.

using(SPSite site = new SPSite(“http://solutionizing.net”)){
webToDispose = site.OpenWeb(“/MyWeb”);
list = webToDispose.Lists["MyList"];
}

By: Is SPList.ParentWeb a Leak? « Solutionizing .NET

Is SPList.ParentWeb a Leak? « Solutionizing .NET — Sun, 10 Aug 2008 05:39:20 +0000

[...] SPList.ParentWeb a Leak? August 10, 2008 — Keith Dahlby As previously discussed, doing the “right thing” with our SPSite and SPWeb references’ [...]

By: SPSite/SPWeb Leaks Revisited « Solutionizing .NET

SPSite/SPWeb Leaks Revisited « Solutionizing .NET — Wed, 23 Jul 2008 06:50:08 +0000

[...] Leaks Revisited July 23, 2008 — Keith Dahlby A while back I posted a rather clumsy technique to mitigate an SPWeb leak discussed here. I knew there had to be a better way, and Rob [...]