Calling dispose???
Peter Johansson
System.ComponentModel.Component and add a OleDbDataAdapter ,a OleDbCommand
and a Typed Dataset with the designer.
I want to dispose MyComp to free up memory manually, Do I have to override
Dispose(bool disposing) to make sure my OleDb-objects also get disposed
right now and not when GC collect it up or is this done automatic when i
call Dispose() method orginally implemented by
System.ComponentModel.Component?
Cowboy (Gregory A. Beamer)
second it is called, as the GC algorithm includes things other than dispose
to determine collection. For example, if a machine is being pounded, the use
of memory may be less of a problem than firing the GC.
Dispose does mark an object as through, so the GC will definitely clean it
on the next pass. It reduces GC overhead to call Dispose, as the GC does not
have to query to find if anything is using the object.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Author: ADO.NET and XML: ASP.NET on the Edge
****************************************************************************
****
Think outside the box!
****************************************************************************
****
"Peter Johansson" <peter.j...@tancom.se> wrote in message
news:u#JwGeHnCHA.1828@TK2MSFTNGP08...
bruce barker
Dispose method for any object you create. the point of inheriting from
Component, is that you are using unmanaged resources that should be freed as
early as possible via Dispose(). you should also implement a Finalize, that
handle cleanup if Dispose is not called.
-- bruce (sqlwork.com)
"Peter Johansson" <peter.j...@tancom.se> wrote in message
news:u#JwGeHnCHA.1828@TK2MSFTNGP08...
Richard McKinnon {Microsoft}
Have a look at this example, I think it will help
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguidnf/ht
ml/cpconimplementingdisposemethod.asp
Cheers,
Richard McKinnon
Microsoft
o This posting is provided “AS IS” with no warranties, and confers
no rights.
Mickey Williams
> of memory may be less of a problem than firing the GC.
A collection is started when more memory is required - it really doesn't
have a whole lot to do with the processor load on the system.
> Dispose does mark an object as through, so the GC will definitely clean it
> on the next pass. It reduces GC overhead to call Dispose, as the GC does
not
> have to query to find if anything is using the object.
Whether or not an object is collected has nothing to do with whether or not
Dispose has been called. All that matters is whether there are any
root-traceable references to the object when the object's generation is
collected. IDisposable and Dispose simply formalize a pattern where types
enable determinstic release of scarce resources that they own. For example,
if you call Dispose on a database connection, the underlying connection
resource is released, but the object will hang around (at least) as long as
there's at least one reference to it.
--
Mickey Williams
Author, "Microsoft Visual C# .NET", Microsoft Press
www.servergeek.com
Cowboy (Gregory A. Beamer)
news:#3xqzbKnCHA.436@TK2MSFTNGP09...
> > For example, if a machine is being pounded, the use
> > of memory may be less of a problem than firing the GC.
>
> A collection is started when more memory is required - it really doesn't
> have a whole lot to do with the processor load on the system.
The algorythm is much more complex than "I need memory, clean some up." The
GC is designed to clean up memory in the most efficient manner, which means
that the CPU load, as well as memory needs are both considered.
When the system is not under load, the GC will fire off from time to time to
clean. This is quite easy to prove through simple observation of a system
with a .NET application running that does not consume large amounts of
memory. You will occasionally see a clearing, if you keep the app up long
enough.
When the system is under load, the GC will wait until a low memory condition
occurs and work to free up some memory to ensure the system continues to
operate properly. This is the most common.
> > Dispose does mark an object as through, so the GC will definitely clean
it
> > on the next pass. It reduces GC overhead to call Dispose, as the GC does
> not
> > have to query to find if anything is using the object.
>
> Whether or not an object is collected has nothing to do with whether or
not
> Dispose has been called. All that matters is whether there are any
> root-traceable references to the object when the object's generation is
> collected. IDisposable and Dispose simply formalize a pattern where types
> enable determinstic release of scarce resources that they own. For
example,
> if you call Dispose on a database connection, the underlying connection
> resource is released, but the object will hang around (at least) as long
as
> there's at least one reference to it.
I do stand corrected on this one. I have done some rather extensive testing,
and have found some interesting ways to introduce bugs with Dispose(),
however.
Mickey Williams
> > > of memory may be less of a problem than firing the GC.
> >
> > A collection is started when more memory is required - it really doesn't
> > have a whole lot to do with the processor load on the system.
>
> The algorythm is much more complex than "I need memory, clean some up."
Actually, that's almost exactly how ephemeral collectors work - divide and
conquer, making most collection passes fast enough that they can be
accomplished without significantly effecting system performance, simplified:
1) I need some memory, look in gen 0.
2) If no memory is available in gen 0, run a GC (starting with gen 0,
degenerate cases may require collection of older generations)
2a) Recover unused blocks
2b) Promote used blocks into a higher generation
2c) Move blocks as needed to improve locality
2d) Gen 0 is now empty
3) Alloc a block in gen 0
Ephemeral collectors typcially wait as long as possible before running
collections passes to minimize the number of blocks promoted into the next
generation. Many books are incorrect in their coverage of this topic, but
see the online documentation, any number of official books and documents
from MS, academic papers on ephemeral collectors, or this online article by
Richter:
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx
If you have documentation for any of your opinions from an official source,
I'd be happy to read it.
Cowboy (Gregory A. Beamer)
for the GC, if I can dig it up, stating it operated on both CPU perf and
memory. From actually testing the assumption, I find that it is based
completely on memory alone. Very interesting indeed. Thanks for putting up
with my bullheadedness.
****************************************************************************
****
Think outside the box!
****************************************************************************
****
"Mickey Williams" <m...@codevtech.com> wrote in message
news:uzXW#XXnCHA.1828@TK2MSFTNGP08...