Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Close those SPSite and SPWeb objects..

  Asked By: Holly    Date: Sep 05    Category: Sharepoint    Views: 1487

We had a problem recently with our w3wp process' crashing. After
talking to MS support, they advised us to make sure that we explicitly
close SPweb and SPSite objects in our web parts, particularly when
iterating through collections. They do not get handled by the .NET
garbage collector, and remain in memory.

I am mentioning it becuase just about every example I have seen does
not do this. Including the ones on the MS site.

Share: 

 

16 Answers Found

 
Answer #1    Answered By: Emmett Hyde     Answered On: Sep 05

Yes that is an excellent idea and one way to handle that is to use using
statement as in:
using(SPWeb spw = new SPWeb)
{
code goes here
}
by using the using statement it will automatically dispose of the object
when done.

 
Answer #2    Answered By: Michelle White     Answered On: Sep 05

I think this might be useful in a project I'm undertaking.

Nice to see that there's a SP Users Group that's been established in NOVA.

 
Answer #3    Answered By: Gopal Jamakhandi     Answered On: Sep 05

We have had problems with that keyword. It stopped any web  part from
working.. No idea why. We tried it to just print out the name of a
site, and it failed. That was late last year though, so maybe things
have changed..

 
Answer #4    Answered By: Jaime Weaver     Answered On: Sep 05

Not if an exception is thrown.

It’s best to use a try/catch/finally block and put the dispose in the finally block.

 
Answer #5    Answered By: Anibal Baird     Answered On: Sep 05

I'm having trouble getting dispose to release memory. Has anyone found a
secret sauce?

 
Answer #6    Answered By: Karla Morrison     Answered On: Sep 05

You must also make sure that if you use GetContext you dispose of it as well.

We just went through a similiar problem, we were having memory  leaks so bad that the app pool was resetting about ever 15-30 minutes. We finally were able to track down all the places where we were not using dispose, now we are not having our memory problems anymore.

We did just add the finally blocks to our try catches to make sure everything was disposed of. We had not tried the Using block yet.

 
Answer #7    Answered By: Patricia Richardson     Answered On: Sep 05

What do you mean it doesn’t “release”? Dispose just makes it available to the garbage collector. There’s no explicit way to fire the GC on a L2 cleanup – you can encourage it but can’t force it.

I can show you an interesting trick w/ WinDbg that I haven’t been able to write up yet. It will cause all of your objects  in memory  to be summarized. It’s really good for showing leaky objects.

 
Answer #8    Answered By: Alexandra Patterson     Answered On: Sep 05

As I crawl thru the entire hierarchy of a SharePoint farm (VS > MP > SC
> RW > SB... LS), memory  consumption grows and grows (rarely
diminishing) but never releases until the console application running
the code is closed. I tried explicit .Close, .Dispose, and set to null
all objects  on last use in the in-line code, and/or in the Finally
clause wherever possible. Microsoft PSS has my proof code and has been
looking at it for nearly two weeks now. I've heard rumblings from their
escalation team that there may not be an effective work around. So, Mark
and I brainstormed the following potential "work arounds" for me to try:

1. Use secondary application domains: While there is some costly
overhead using an interface factory to setup each app domain and the
code is significantly more complex than my current solution, it will
probably be my best bet for getting memory to release when I want it to.
2. Replace foreach loops with for index loops: I realize that this will
result in very costly API lookups (hydrating the entire collection for
every SPSite and every SPWeb object retrieved) but it may allow the GC
to release memory I think may be held due to the way that foreach
pre-fetches collection items (maybe there is still a reference being
help by the API so the object isn't disposed when I expect it to).
3. Dropping the SPGlobalAdmin object after processing each Virtual
Server: I don't have high hopes for this approach. I've already
demonstrated that memory isn't released until after the console window
closes, but perhaps there is a timing issue here.

If anyone has any other potential "work arounds" for me to try, I'm all
ears.

 
Answer #9    Answered By: Christop Mcfadden     Answered On: Sep 05

I think the problem  is that these are COM objects  underneath, and as such are not handled by the GC. So it doesn't matter if you force the clean up with the GC or not, they will stay out there because they are COM. I'm not sure why it's not releasing until the console app closes, we've not had any problems after we double checked and wrapped everything with try.catch.finally blocks to make sure that everything was getting closed. One note, we did have to call close  on all the objects, and not dispose to get them to release memory.

 
Answer #10    Answered By: Stefanie Ruiz     Answered On: Sep 05

According to the PSS guy we talked to, indexing can have the same
effect as using foreach.

As for work-arounds, we went the direct db access route. We have an
alert web  part that gets a list of sites from the db, and then we use
the object model. When we were talking to the PSS guy, we rewrote it
to use the om using tips he gave us, and it took 5+ minutes to load
the page with one user on the server. With db access it takes maybe 5
seconds when we have about 200 users on it.

Obviously, direct db access is not the ideal way to be doing this, but
in my case it was just a read, and it works. Here is hoping I can get
rid of it for the next version.

 
Answer #11    Answered By: Damon Garner     Answered On: Sep 05

The dispose methods of the .net objects  are supposed to call Marshal.ReleaseComObject (or whatever the precise name is) on the underlying COM objects to free them. So it’s supposed to be OK for the GC to go get…

 
Answer #12    Answered By: Royce Orr     Answered On: Sep 05

Yes, but the freeing is done on the COM side, the GC will collect the .Net objects  if I'm not mistaken. So the com resources/memory should be freed immediately, while the .Net objects will go through the normal GC cycles before they are actually released.

Have I mentioned how I can't wait to go to V3.

 
Answer #13    Answered By: Laura Walker     Answered On: Sep 05

You’ve definitely got my attention because my site  propagation tool does large amounts of work with the APIs and I’ve not seen an out of memory  exception, yet.

blog (http://blogs.msdn.com/maoni) has some good GC information that may help you think about some ideas for memory freeing.

The WinDbg technique can help you actually see what’s being held on to… The SP API is a most likely candidate but you never know …

Who’s working on the MS case?

 
Answer #14    Answered By: Nina Banks     Answered On: Sep 05

Direct data base access is definitely not an option.

 
Answer #15    Answered By: Renee Murray     Answered On: Sep 05

You could always store the sites in a list. Either add the site  to the
list as it is being created, or run an occasional program which would
search the servers and populate the list.

 
Answer #16    Answered By: Harshini Raju     Answered On: Sep 05

Try creating a survey. Hide the persons name and the permissions and set alerts.

 
Didn't find what you were looking for? Find more on Close those SPSite and SPWeb objects.. Or get search suggestion and latest updates.




Tagged: