Comments on Chris O'Brien: Disposing SharePoint objects - what they don't tel...

Interesting comments - these are good contribution...

2008-06-16T12:27:00.000+01:00

Interesting comments - these are good contributions, thanks.

Keith - I like your idea, it's a nice alternative to my suggestion. One drawback however is it works well for a small call stack (like my example), but similar to Tojonas' comment, not so well for a more complex pattern - you'd need to pass your out parameter around between methods/classes. This is avoided to a certain extent in my structure, where you only need the SPList/SPListItem which you could be passing around for actual use.

Still, I'm not sure either is a real solution to the deeper problem Jonas points out very well. I'm not sure I'd go as far as to say the OM is broken, but it sure is tricky to write library code around the API. Jonas, if you give any further consideration to your layer I'd be interested to hear more, but I can also see there could be interesting issues around class responsiblity there.

I have a follow-up post which expands on these kind of issues soon.

Chris.

Thanks for a good post.

The problem is that...

2008-06-16T08:59:00.000+01:00

Thanks for a good post.

The problem is that this doesn't scale at all.

You have already touched on the problem of writing LIBRARY code for SharePoint, and that is what I'm talking about below.

In my opinion it's IMPOSSIBLE to do it "correct" since sometimes you should dispose of objects and sometimes you shouldn't. (Remember that I'm talking about library code where the method has no knowledge about how the SPWeb and SPSite was constructed)

The deeper your call stack gets the more impossible it gets.

In your example you only have two levels. Your main method and then you get the objects using two helper methods. And you had to intoduce a flag to know when to dispose or not.

Just imagine that you have more nested calls and you see it can't be done.

The reason I say it can't be done is that we have been told that just by accessing some properties of the OM new SPWeb objects have been created and it's UP TO US as clients of the OM to dispose of these.

And since the OM is caching all the references and returning the same instance (as you showed with your GetHashCode() sample) we can't even DO this since we might dispose of an object that are later being used in another method.

When we call dispose on the object the ObjectModel doesn't know about this so it's internal member is still set to the same object but NOW THIS OBJECT is disposed !!!

The OM is unfortunately broken.

The only safe way is to NEVER dispose of any objects UNLESS you have explicitly created them yourself.

I'm considering writing a facade ontop of the OM that will reference count everything returned and the client has to dispose of EVERYTHING EVERYTIME and it's up to this layer to now when to actually call dispose.

Thanks
/Jonas

Chris ~

I've posted a possible alternative ...

2008-06-16T04:19:00.000+01:00

Chris ~

I've posted a possible alternative approach here. Let me know what you think.

Cheers ~
Keith

A part of the problem is that Microsoft uses the I...

2008-06-15T22:08:00.000+01:00

A part of the problem is that Microsoft uses the IDisposable interface inconsistently. SPWeb implements it, but SPList doesn't, even though both can contain a reference to a SPRequest object. And that's not the only case where a class that doesn't implement IDisposable can create objects that do require disposing. While you could use Reflector to find out which methods cause an SPRequest to be instantiated, you shouldn't have to rely on implementation details.

You can avoid this somewhat by instatiating any SPWebs and SPSites that you might need early and dispose those at the very last moment, but that means you'll be holding onto objects longer than necessary and using more resources than you need while your code is running. It still beats the alternative, though.

Comments on Chris O'Brien: Disposing SharePoint objects - what they don't tel...

Interesting comments - these are good contribution...

Thanks for a good post.The problem is that...

Chris ~I've posted a possible alternative ...

A part of the problem is that Microsoft uses the I...

Thanks for a good post.

The problem is that...

Chris ~

I've posted a possible alternative ...