You need to ensure that there are no memory leaks in th…

A company uses SharePoint for internal collaboration. SharePoint is deployed on a server farm with a single
front-end server, a single application server, and a dedicated database server.
You review existing Web Parts that read from and write to SharePoint lists. You find the following code in one of
the utility classes and notice memory leaks in the method.

You need to ensure that there are no memory leaks in the method.
What should you do?

A company uses SharePoint for internal collaboration. SharePoint is deployed on a server farm with a single
front-end server, a single application server, and a dedicated database server.
You review existing Web Parts that read from and write to SharePoint lists. You find the following code in one of
the utility classes and notice memory leaks in the method.

You need to ensure that there are no memory leaks in the method.
What should you do?

A.
Add a finally statement and include site.Dispose ().

B.
Add site.Dispose() to the catch statement.

C.
Add a finally statement and include siteCollection.Dispose ();

D.
Add siteCollection.Dispose() to the catch statement.

Explanation:
Need to manually dispose of the siteCollection instance. This can be done through a finally statement.
Note:
* Try and finally blocks or a using statement would be required to avoid potential leaks when you create a
disposable object within a foreach block, as shown in the following code example.
SPWebApplication webApp = siteCollectionOuter.WebApplication;
SPSiteCollection siteCollections = webApp.Sites;
SPSite siteCollectionInner = null;
foreach (siteCollectionInner in siteCollections)
{
try //Should be first statement after foreach.{
Console.WriteLine(siteCollectionInner.Url);
//Exception occurs here.
}
finally
{
if(siteCollectionInner != null)
siteCollectionInner.Dispose();
}
}
* 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



Leave a Reply 0

Your email address will not be published. Required fields are marked *