http://blogs.msdn.com/sharepoint/archive/2008/11/12/announcing-spdisposecheck-tool-for-sharepoint-developers.aspx
So what is SPDisposeCheck
"SPDisposeCheck, will open your custom compiled assemblies recursively and validate them against the Microsoft published guidance. The output from the tool will contain messages that may indicate the SPSite and SPWeb Dispose() methods guidance is are not being followed in the customers source code. While these messages need expert evaluation in order to determine if the software is not performing properly, in some cases just running the tool on your custom code can lead you to simple fixes that improve the quality and performance of custom code on SharePoint. "
"This tool is planned for release during the coming North American Winter. Customers who are currently experiencing difficulties with memory management in their custom applications should review the guidance listed above. Customers who are currently experiencing difficulties with Microsoft Office SharePoint Server 2007 should contact their regular Microsoft Customer Support Services contact, or refer to http://support.microsoft.com/."
Disposing of SharePoint objects correctly is a big problem in custom developed code, if your SharePoint implementation is constantly "Dieing" ie, after regular use the memory and cpu max out and you need to reboot your server to get things going again then its highly likely you are running custom SharePoint Object Model code that is not correctly disposing of objects causing memory leaks. The rate of memory leakage can be significant.
I have since this ugly problem rear its head in a number of projects I have been involved in. So yeah when you finally do fixup the problem and dispose of objects correctly you will notice the improvement of system performance and your server should run as if it has a simple vanilla install of SharePoint.
Another major problem with this is that.... These Dispose() rules are COMPLEX. The biggest problem faced is the difference in coding patterns depending on where your custom code is running.
ie. If your SharePoint OM code is running in a Web Part or Custom Control then you have access to the SPContext.Current object which is your starting point to get to your SPSite, SPWeb, SPList, SPListItem, SPFile etc. etc. its important to note that objects accessed from the current context should not be disposed of. The SPContext.Current.Site and its SPWebs that hang of it are singletons and should not be disposed as SharePoint makes use of these and will need to possibly use these objects after your custom code executes. That means the using(SPWeb =...) pattern will dispose of objects you are not meant to, you will get an error.
BUT - if you are running the code in a console app or 'out-of-context' then you should always dispose the objects as you are the one creating them.
Confused? Complicated? Yeh it is but it is important to understand the issues if you are writing custom SharePoint Object Model code.
Thursday, 13 November 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment