Note This article refers to the following Microsoft .NET Framework Class Library namespace:
System.EnterpriseServices.ServicedComponent
When you run an
application that contains components that are derived from
System.EnterpriseServices.ServicedComponent, the system memory usage may
increase to more than 60 percent of the available memory. For example, if you run an ASPX application, the system memory usage may increase. Handle counts may also increase more than
you expect. High CPU usage may be indicated in Windows Task Manager while the
Req/Sec value remains at a reasonable level. If you examine managed heaps and
unmanaged heaps, you find no evidence of memory leaks or of handle
leaks. When
Object.Finalize requests stop, the memory usage and the handle count eventually fall to
more reasonable levels.
This problem may occur if the current version of the
common language runtime is limited to one finalizer thread. If there are many
worker threads manipulating managed finalizable objects, the finalizer thread
can fall behind. In this scenario, the finalizer thread can fall behind especially if significant work occurs in the finalizer of each
object. Serviced components may be vulnerable to this design issue because handles
are held alive based on the COM+ object context. This is also true of other
managed objects with complicated finalizers.
To resolve this problem, follow the common language runtime coding pattern by calling
the
Dispose method and the
Dispose object when you finish with the managed objects that
support
IDisposable. Service component is a managed class that supports
IDisposable.