Daniel, Where there is a Close() it will invariably call Dispose().
Also classes that implement IDisposeable will call Dispose() from the (always) implemented Finalize method (destructor). Leaving it up to the Finalize method to call Dispose() has two direct impacts on application performance and memory management. 1. When an object is created and it implements the Finalize() method, a pointer to the object is created on the Finalisation List. The Finalisation list contains entries for objects on the managed heap that need to have their Finalize() method called before they can be garbage collected. When an object is considered done with and no longer referenced by the application, the reference to the object is moved to the 'freachable queue' which will then be processed by the Finaliser thread the next time it wakes up. Application performance can degrade because the finaliser thread has all these object's Finalize methods to work through (each one calling Dispose()). The more the finaliser thread stays asleep the faster your app will run. 2. A reference to an object from the freachable queue means that it is still regarded as reachable and therefore the memory occupied by it will not be collected during the next garbage collection while it is still being referenced from the queue. Its entirely possible for objects that you no longer have a use for to be promoted to an older generation on the heap during garbage collection before the finaliser wakes up and processes the freachable queue. An explicit call to Dispose() ensures that you are releasing potentially valuable resources early, but also importantly the Dispose() method will call GC.SuppressFinalize() which ensures that the object is truly regarded as unreachable and can be garbage collected early. i.e. it will have the reference to it in the finalise list removed and not moved to the freachable queue. If there's a Dispose() method present in a class its there for a reason. I always call it when I'm done. And Peter is obsolutely correct in his assertion that although Dispose(), on inspection of the IL code, may not appear to do anything of great importance, in later versions of that class it may and most probably will. There's also a rather handy using() statement that causes the c# compiler to automatically generates IL code that calls the Dispose() method for you. For an example of an implemented IDisposable pattern see: help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconimplementingdisposemethod.htm I hope I explained that ok and hope it helps to reassure you that calling Dipose() is a good thing to do. Kev > -----Original Message----- > From: Peter Foreman [mailto:[EMAIL PROTECTED]] > Sent: 12 June 2002 20:51 > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] ADO.NET and Dispose > > > --- Daniel Morgan <[EMAIL PROTECTED]> wrote: > > If I read the docs correctly, Close ( ) calls Dispose ( ) for the > > Connection. > > Yes. > > > However, I would like to know more about the proper way to > dispose of > > resources. > > If an object implements Dispose() then you should call it > when you are completely done with that object. Ideally this > will be asap after you are done with the object to achieve > maximum scalability. > > If Dispose was put in an object's public interface then it is > not without reason. The problem is there are different > levels of importance for different resources, you may get > away without calling some. Better safe than sorry though. > If you skip Dispose() then it may not do anything in version > 1 of the object you're using, but there is no saying that it > will not be required in version 2. If there is one thing > that COM taught it is always to program to the rules, even > when it appears you may be 'getting away with it' for now. > > Peter > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
