Folgende Artikel behandeln das Thema oder die Auswirkung: * Best Practices: Using Disposable Windows SharePoint Services Objects
http://msdn2.microsoft.com/en-us/library/aa973248.aspx * Best Practices: Common Coding Issues When Using the SharePoint Object Model
http://msdn2.microsoft.com/en-us/library/bb687949.aspx * Stefan Gossner: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007
http://blogs.technet.com/stefan_gossner/archive/2008/05/07/troubleshooting-spsite-spweb-leaks-in-wss-v3-and-moss-2007.aspx
Es ist leider noch immer so, dass hinter den .NET Schichten eine Menge (D)COM(+) liegt. In der .NET Welt ist man “leider” ja nicht mehr gezwungen, sich gezielt um speicher zu kümmern. Leider wird das unerfahrenen aber auch erfahrenen Entwicklern immer wieder zum Stolperstein. Genau wie beim Zugriff auf Datenbanken (Thema: Connection Pool Limit) und beim Lesen und Schreiben von Dateien, kommt es immer wieder zu Problemen. In einer WebAnwendung kommen diese Effekte in der Regel deutlich stärker zum Tragen, als in Windows Anwendungen, da das Beenden der Anwendung in den meisten Fällen auch die genutzten Ressourcen wieder frei gibt. So kommen die SQL Connections wieder in den Pool, sobald zum Beispiel die CommandLine Applikation nach dem Ausführen automatisch geschlossen wird. In einer WebAnwendung leben die Objekte im W3P (seit dem IIS6, also pro ApplicationPool). Ob und wann dieser beendet wird, ist von vielen Parametern abhängig. In der Regel lebt der Prozess allerdings länger als seine Verwandten auf dem Desktop. Es kommt hinzu, dass die Useranzahl in der Regel höher ist also bei einem Windows Programm.
Ein guter SharePoint Programmierer muss also wissen, was hinter seinen Objekten steckt. Leider ist es es auch nicht so einfach immer ein Dispose aufzurufen, wo es angeboten wird :-S Ein Sharepoint Objekt das direkt aus dem SPContext kommt, wurde zum Beispiel nicht von dem Programmierer erstellt und somit ist er auch nicht für das schließen verantwortlich. Er darf es sogar nicht schlichen, da noch anderer Programmcode nach ihm das Objekt benötigt. Es wird also deutlich, dass es darauf ankommt, wo ich meine Objekte her bekomme. In der Regel ist man gut beraten, die MS Guides zu lesen und diese zu befolgen. Ein MS SharePoint Objekt, welches das IDisposable Interface implementiert, sollte auf jeden Fall geprüft werden, ob es geschlossen werden muss.
Wenn man nun solche Probleme hat, sollte man sich einfach den Artikel von Stefan Grosser ansehen. Es wird schnell klar, dass es nicht trivial ist, die Quelle zu finden. Selbstgeschriebener oder eingekaufter Code kann die Quelle für Speicherprobleme sein, allerdings gibt es auch genug andere Ursachen, die von MS direkt kommen. Zumindest läßt der eine oder andere KB Artkel darauf schließen.
Also dann happy coding.
Ciao Marco