I have read in various places that un-disposed SPWeb/SPSite objects keeps valuable database connections open and large COM objects in memory. Not disposing those objects is like number one mistake SharePoint newbies tend to commit.

I've been abiding those rules since time immemorial, but I am curious on the exact implications of open SP objects.

How are database connections consumed? Is it per user, per SPWeb, something else? How much memory do those COM objects consume? At what scale does this become a problem?

Edit: As for the database connection part, I am referring to this article: http://blogs.technet.com/b/stefan_gossner/archive/2008/12/05/disposing-spweb-and-spsite-objects.aspx

1 Answer 1


It got nothing to do with database, when you create a new object it reserves some space or memory in RAM.

It is per object, for example when you use SPSite site = new SPSite(URL);it creates a object SPSite in memory.

There was a scenario when I had to go through hundred of sub-webs of a site collection and I forgot to dispose SPWeb and it crashed development server.

I would suggest you to use SPDisposeCheck tool for Visual studio to find out if your code is disposing all objects it should.

Why Dispose?

Several of the Windows SharePoint Services objects, primarily the SPSite class and SPWeb class objects, are created as managed objects. However, these objects use unmanaged code and memory to perform the majority of their work. The managed part of the object is much smaller than the unmanaged part. Because the smaller managed part does not put memory pressure on the garbage collector, the garbage collector does not release the object from memory in a timely manner. The object's use of a large amount of unmanaged memory can cause some of the unusual behaviors described earlier. Calling applications that work with IDisposable objects in Windows SharePoint Services must dispose of the objects when the applications finish using them. You should not rely on the garbage collector to release them from memory automatically.

Best Practices: Using Disposable Windows SharePoint Services Objects


The blog you are providing reference to, if you read the comments on blog post you will figure out the author accepts that he was providing some wrong and created a new blog post, hence I won't recommend you to go through that blog post, but MSDN article I gave you link to is enough for understandings.

  • Thanks for sharing your experience, can you elaborate more on that? you mention it crashed the development server, what did you use development server for?
    – Bill Yang
    Mar 20, 2013 at 19:20
  • There are different stages before deploying solutions to production server, development server is where developer test there code and its just like a copy of integration or production server. Mar 20, 2013 at 19:23
  • Ah I somehow thought you were referring to VS development server. Now that's interesting, because I did a similar test with a console app opening 100 SPSite/Web, which does not seem to affect the server in any noticeable manner. Which brings the question: how much resource do SPRequest consume? And is it different under different circumstances?
    – Bill Yang
    Mar 20, 2013 at 19:35
  • 1
    I would recommend you to post another question instead of commenting on this answer to keep things consistent. Mar 20, 2013 at 19:42
  • 2
    How much resources SPRequest consumes is entirely dependant on what you do with it. If you simply just open it then open another, it won't consume that much as only an initial amount of metadata is loaded. Get some lists, iterate some list items, create some lists, create some sites, etc.. and the SPRequest object stores more and more in memory.
    – James Love
    Mar 20, 2013 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.