Windows SharePoint Services Objects

The objects in the model of Windows SharePoint Services 3.0 to serve as an interface for working with data services from Windows SharePoint Services. Often, developers bring in the object model to read data or write new data in the warehouse of Windows SharePoint Services.
Windows SharePoint Services object model contains objects that implement the IDisposable interface. You should take precautions when using these objects to avoid long-term retention in memory at Microsoft. NET Framework.
In particular, explicitly, you must have SharePoint objects that implement IDisposable when you are finished using them.
In situations in which objects are used widely SharePoint, for example, SharePoint sites that use custom Web Parts, can cause the following unusual behaviors for lack of SharePoint object when finished with them.

• Common pool recycled from Windows SharePoint Services implementation, especially during peak usage
• Application crashes that appear as the corruption of the heap in the debugger
• The high memory usage for Microsoft Internet Information Services (IIS) worker processes
• Poor system and application performance

Why Dispose?

Several of the Windows SharePoint Services objectives, mainly the SPSite class and SPWeb class objects, are made 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 massive amount of unmanaged memory can cause a quantity 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.

You can identify the potential presence of incorrectly disposed objects by asking the following questions:

• Does your application pool recycling frequently, especially under heavy loads (assuming that the application pool set to recycle when it reaches a threshold of memory)?
• The threshold of the memory should be 800 MB 1.5 GB (assuming that at least 2 GB of RAM). Setting application pool recycling occurs about 1 GB offers the best results, but the experiment to determine what settings work best for your environment. If recycling value is too low, you experience performance problems due to frequent application pool recycles. If the value is too high, your system is experiencing performance problems due to the exchange site, the memory fragmentation and other issues.
• Does the system perform poorly, especially under heavy loads?
  As the memory usage begins to increase, the system must compensate, for example, memory paging and manipulation of memory fragmentation.
• Does your system crash or cause users to experience unexpected errors such as timeouts or page not available errors, especially with heavy loads?
  Again, when it is fragmented memory usage increases or fail because some functions can not allocate memory for other operations. In many cases, the code does not properly handle the "memory" exception error that leads to false or misleading.
• Does your system use custom or third-party Web Parts or custom applications?
  It might not be aware that objects must have SharePoint and why, assuming that garbage collection performs this function automatically. But that is not true in all cases.