Memory leak! (ADO.NET, VB.NET) 
Author Message
 Memory leak! (ADO.NET, VB.NET)

Hi,
    I have a few classes that have ADO.NET functionality in them.
    When I call the objs (my custom ones) form my ASP.NET or VB.NET apps,
the memory just goes up and up and up. I am guessing that I am not closeing
something.

    I was under the impression that I could just do a obj = Nothing and that
would do the trick.
    What should I be doing in the ADO.NET part and in the Class part?

Thanks..
George.



Tue, 15 Feb 2005 23:55:10 GMT  
 Memory leak! (ADO.NET, VB.NET)
Setting objects to Nothing could only help. Although the Net garbage
collector should remedy this and make this step unnecessary (I still do it
as a force of habit from VB days).

More importantly, any ADO.NET object that has a close method, such as the
connection and data reader objects, should be implemented in code.  This
most undoubtedly will cure your memory leak problem.

Hope this helps.
--
Peter O'Reilly



Wed, 16 Feb 2005 00:12:58 GMT  
 Memory leak! (ADO.NET, VB.NET)
You may not have a memory leak at all. DotNet garbage collection works
differently than previous technologies. When references to an object become
0, previously the object would be removed from memory immediately. Now the
object remains in memory for a time (depending on how much memory is
available to the system) and cleaned up later. This may give you the
impression that you're experiencing a memory leak, when there isn't one.

--
Kevin Spencer
Microsoft FrontPage MVP
Internet Programmer
For ASP Tutorials and Information -
http://www.takempis.com



Quote:
> Hi,
>     I have a few classes that have ADO.NET functionality in them.
>     When I call the objs (my custom ones) form my ASP.NET or VB.NET apps,
> the memory just goes up and up and up. I am guessing that I am not
closeing
> something.

>     I was under the impression that I could just do a obj = Nothing and
that
> would do the trick.
>     What should I be doing in the ADO.NET part and in the Class part?

> Thanks..
> George.



Wed, 16 Feb 2005 01:22:48 GMT  
 Memory leak! (ADO.NET, VB.NET)
Ken's right. This means that on systems with lots of memory, the
time-consuming task of cleaning out unused objects and freeing the space
does not take place for quite some time. Since developers used to depend on
the VB runtime garbage collector to do things like close connections, we now
have to be more careful to make sure DataReaders and Connections are closed
before they fall from our control (scope). This has other implications as
well. Other applications competing for memory are also challenged as the
memory is being used and not released (immediately) by the .NET CLR and
until it's all allocated, the garbage collector won't release it. When
memory is finally released, I expect you'll see a CPU spike as it cleans up
the dormant objects. I expect that there's a way to limit the amount of
memory used by a .NET application.
--
William (Bill) Vaughn
Author, Trainer, Mentor
Microsoft Pacwest Regional Director
Beta V Corporation
"ADO and ADO.NET Examples and Best Practices for VB Programmers--2nd
Edition" (ISBN: 1-893115-68-2)
"ADO.NET Examples and Best Practices for C# Programmers" (ISBN:
1-590590-12-0)

www.betav.com

Please reply only to the newsgroup so that others can benefit. When posting,
This posting is provided "AS IS" with no warranties, and confers no rights.
________________________________


Quote:
> You may not have a memory leak at all. DotNet garbage collection works
> differently than previous technologies. When references to an object
become
> 0, previously the object would be removed from memory immediately. Now the
> object remains in memory for a time (depending on how much memory is
> available to the system) and cleaned up later. This may give you the
> impression that you're experiencing a memory leak, when there isn't one.

> --
> Kevin Spencer
> Microsoft FrontPage MVP
> Internet Programmer
> For ASP Tutorials and Information -
> http://www.takempis.com



> > Hi,
> >     I have a few classes that have ADO.NET functionality in them.
> >     When I call the objs (my custom ones) form my ASP.NET or VB.NET
apps,
> > the memory just goes up and up and up. I am guessing that I am not
> closeing
> > something.

> >     I was under the impression that I could just do a obj = Nothing and
> that
> > would do the trick.
> >     What should I be doing in the ADO.NET part and in the Class part?

> > Thanks..
> > George.



Wed, 16 Feb 2005 01:36:37 GMT  
 Memory leak! (ADO.NET, VB.NET)
Implement iDispose interface. Then before you close your objects, call the
Dispose method.

In your dispose method, dispose of all the the child objects. Set string
objects to empty strings. Then set to nothing.

BTW: Setting objects to nothing is still a good habit. By doing this, you
may be allowing the garbage collector to operate sooner by releasing
refrence earlier.

If you are realy concerned about memory, you can force the garbage collector
to clean up memory at your will.

     System.GC.Collect()

Brian Webb



Quote:
> Hi,
>     I have a few classes that have ADO.NET functionality in them.
>     When I call the objs (my custom ones) form my ASP.NET or VB.NET apps,
> the memory just goes up and up and up. I am guessing that I am not
closeing
> something.

>     I was under the impression that I could just do a obj = Nothing and
that
> would do the trick.
>     What should I be doing in the ADO.NET part and in the Class part?

> Thanks..
> George.



Wed, 16 Feb 2005 02:08:51 GMT  
 Memory leak! (ADO.NET, VB.NET)
there are basically two types of objects in .net

1) pure managed objects. these objects only allocate memory/resources  from
the clr. you can safely ignore cleanup of these objects as the garabage
collector will handle them for you.

2) clr object that call unmanaged code that uses unmanged resources (c-heap,
gdi resources, files, os resources). these object should implement the
IDispose interface. objects of this type you must take great care with. most
implement a close() function, but many depend on you call the dispose()
method when done. you need to release the unmanged resouce as soon as
possible, because the garabage collector may not collect the object until
task exit. the object may not use many managed resoures (gc memory), so it
is never collected.

when using any object that implements IDispose you should use a finally
statement to release its unmanaged resources (call its Close or Dispose
methods). if using C# use the using statement when creating these objects.

note - if you wrap any object that implements IDispose and you don't
Dispose() it in the the same method that creates it, your object should also
implement IDispose (read the manual carefully as they are a little tricky to
get right) or you will have resource leaks.

-- bruce (sqlwork.com)



Quote:
> Ken's right. This means that on systems with lots of memory, the
> time-consuming task of cleaning out unused objects and freeing the space
> does not take place for quite some time. Since developers used to depend
on
> the VB runtime garbage collector to do things like close connections, we
now
> have to be more careful to make sure DataReaders and Connections are
closed
> before they fall from our control (scope). This has other implications as
> well. Other applications competing for memory are also challenged as the
> memory is being used and not released (immediately) by the .NET CLR and
> until it's all allocated, the garbage collector won't release it. When
> memory is finally released, I expect you'll see a CPU spike as it cleans
up
> the dormant objects. I expect that there's a way to limit the amount of
> memory used by a .NET application.
> --
> William (Bill) Vaughn
> Author, Trainer, Mentor
> Microsoft Pacwest Regional Director
> Beta V Corporation
> "ADO and ADO.NET Examples and Best Practices for VB Programmers--2nd
> Edition" (ISBN: 1-893115-68-2)
> "ADO.NET Examples and Best Practices for C# Programmers" (ISBN:
> 1-590590-12-0)

> www.betav.com

> Please reply only to the newsgroup so that others can benefit. When
posting,
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> ________________________________



> > You may not have a memory leak at all. DotNet garbage collection works
> > differently than previous technologies. When references to an object
> become
> > 0, previously the object would be removed from memory immediately. Now
the
> > object remains in memory for a time (depending on how much memory is
> > available to the system) and cleaned up later. This may give you the
> > impression that you're experiencing a memory leak, when there isn't one.

> > --
> > Kevin Spencer
> > Microsoft FrontPage MVP
> > Internet Programmer
> > For ASP Tutorials and Information -
> > http://www.takempis.com



> > > Hi,
> > >     I have a few classes that have ADO.NET functionality in them.
> > >     When I call the objs (my custom ones) form my ASP.NET or VB.NET
> apps,
> > > the memory just goes up and up and up. I am guessing that I am not
> > closeing
> > > something.

> > >     I was under the impression that I could just do a obj = Nothing
and
> > that
> > > would do the trick.
> > >     What should I be doing in the ADO.NET part and in the Class part?

> > > Thanks..
> > > George.



Wed, 16 Feb 2005 05:23:49 GMT  
 Memory leak! (ADO.NET, VB.NET)
Bruce, are any of the ADO.NET objects "unmanaged"? I thought they were all
managed code. I expect that ADO classic (COM-based ADO) is an example of an
unmanaged object.

--
William (Bill) Vaughn
Author, Trainer, Mentor
Microsoft Pacwest Regional Director
Beta V Corporation
"ADO and ADO.NET Examples and Best Practices for VB Programmers--2nd
Edition" (ISBN: 1-893115-68-2)
"ADO.NET Examples and Best Practices for C# Programmers" (ISBN:
1-590590-12-0)

www.betav.com

Please reply only to the newsgroup so that others can benefit. When posting,
This posting is provided "AS IS" with no warranties, and confers no rights.
________________________________


Quote:
> there are basically two types of objects in .net

> 1) pure managed objects. these objects only allocate memory/resources
from
> the clr. you can safely ignore cleanup of these objects as the garabage
> collector will handle them for you.

> 2) clr object that call unmanaged code that uses unmanged resources
(c-heap,
> gdi resources, files, os resources). these object should implement the
> IDispose interface. objects of this type you must take great care with.
most
> implement a close() function, but many depend on you call the dispose()
> method when done. you need to release the unmanged resouce as soon as
> possible, because the garabage collector may not collect the object until
> task exit. the object may not use many managed resoures (gc memory), so it
> is never collected.

> when using any object that implements IDispose you should use a finally
> statement to release its unmanaged resources (call its Close or Dispose
> methods). if using C# use the using statement when creating these objects.

> note - if you wrap any object that implements IDispose and you don't
> Dispose() it in the the same method that creates it, your object should
also
> implement IDispose (read the manual carefully as they are a little tricky
to
> get right) or you will have resource leaks.

> -- bruce (sqlwork.com)



> > Ken's right. This means that on systems with lots of memory, the
> > time-consuming task of cleaning out unused objects and freeing the space
> > does not take place for quite some time. Since developers used to depend
> on
> > the VB runtime garbage collector to do things like close connections, we
> now
> > have to be more careful to make sure DataReaders and Connections are
> closed
> > before they fall from our control (scope). This has other implications
as
> > well. Other applications competing for memory are also challenged as the
> > memory is being used and not released (immediately) by the .NET CLR and
> > until it's all allocated, the garbage collector won't release it. When
> > memory is finally released, I expect you'll see a CPU spike as it cleans
> up
> > the dormant objects. I expect that there's a way to limit the amount of
> > memory used by a .NET application.
> > --
> > William (Bill) Vaughn
> > Author, Trainer, Mentor
> > Microsoft Pacwest Regional Director
> > Beta V Corporation
> > "ADO and ADO.NET Examples and Best Practices for VB Programmers--2nd
> > Edition" (ISBN: 1-893115-68-2)
> > "ADO.NET Examples and Best Practices for C# Programmers" (ISBN:
> > 1-590590-12-0)

> > www.betav.com

> > Please reply only to the newsgroup so that others can benefit. When
> posting,
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > ________________________________



> > > You may not have a memory leak at all. DotNet garbage collection works
> > > differently than previous technologies. When references to an object
> > become
> > > 0, previously the object would be removed from memory immediately. Now
> the
> > > object remains in memory for a time (depending on how much memory is
> > > available to the system) and cleaned up later. This may give you the
> > > impression that you're experiencing a memory leak, when there isn't
one.

> > > --
> > > Kevin Spencer
> > > Microsoft FrontPage MVP
> > > Internet Programmer
> > > For ASP Tutorials and Information -
> > > http://www.takempis.com



> > > > Hi,
> > > >     I have a few classes that have ADO.NET functionality in them.
> > > >     When I call the objs (my custom ones) form my ASP.NET or VB.NET
> > apps,
> > > > the memory just goes up and up and up. I am guessing that I am not
> > > closeing
> > > > something.

> > > >     I was under the impression that I could just do a obj = Nothing
> and
> > > that
> > > > would do the trick.
> > > >     What should I be doing in the ADO.NET part and in the Class
part?

> > > > Thanks..
> > > > George.



Wed, 16 Feb 2005 07:50:33 GMT  
 Memory leak! (ADO.NET, VB.NET)

Quote:

> BTW: Setting objects to nothing is still a good habit. By doing this, you
> may be allowing the garbage collector to operate sooner by releasing
> refrence earlier.

Actually no. You will find posts from MSFT that explain that one of the
optimisations that did make the 1.0 release was that the jitter notices the
last use of an object reference. Referring to the object reference to set it
to Nothing can stop this optimisation.

Simply, x =  Nothing implicitly occurs immediately after the last use of x.
There's a GC.KeepAlive(x) routine to explicitly stop this feature when it
matters -- you call it after the region where x must not be GCed.

ms-help://MS.NETFrameworkSDK/cpref/html/frlrfSystemGCClassKeepAliveTopic.htm

Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)



Sat, 19 Feb 2005 11:21:33 GMT  
 Memory leak! (ADO.NET, VB.NET)
That is correct.

HTH,

--
Kevin Spencer
Microsoft FrontPage MVP
Internet Programmer
For ASP Tutorials and Information -
http://www.takempis.com



Quote:
> Bruce, are any of the ADO.NET objects "unmanaged"? I thought they were all
> managed code. I expect that ADO classic (COM-based ADO) is an example of
an
> unmanaged object.

> --
> William (Bill) Vaughn
> Author, Trainer, Mentor
> Microsoft Pacwest Regional Director
> Beta V Corporation
> "ADO and ADO.NET Examples and Best Practices for VB Programmers--2nd
> Edition" (ISBN: 1-893115-68-2)
> "ADO.NET Examples and Best Practices for C# Programmers" (ISBN:
> 1-590590-12-0)

> www.betav.com

> Please reply only to the newsgroup so that others can benefit. When
posting,
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> ________________________________



> > there are basically two types of objects in .net

> > 1) pure managed objects. these objects only allocate memory/resources
> from
> > the clr. you can safely ignore cleanup of these objects as the garabage
> > collector will handle them for you.

> > 2) clr object that call unmanaged code that uses unmanged resources
> (c-heap,
> > gdi resources, files, os resources). these object should implement the
> > IDispose interface. objects of this type you must take great care with.
> most
> > implement a close() function, but many depend on you call the dispose()
> > method when done. you need to release the unmanged resouce as soon as
> > possible, because the garabage collector may not collect the object
until
> > task exit. the object may not use many managed resoures (gc memory), so
it
> > is never collected.

> > when using any object that implements IDispose you should use a finally
> > statement to release its unmanaged resources (call its Close or Dispose
> > methods). if using C# use the using statement when creating these
objects.

> > note - if you wrap any object that implements IDispose and you don't
> > Dispose() it in the the same method that creates it, your object should
> also
> > implement IDispose (read the manual carefully as they are a little
tricky
> to
> > get right) or you will have resource leaks.

> > -- bruce (sqlwork.com)



> > > Ken's right. This means that on systems with lots of memory, the
> > > time-consuming task of cleaning out unused objects and freeing the
space
> > > does not take place for quite some time. Since developers used to
depend
> > on
> > > the VB runtime garbage collector to do things like close connections,
we
> > now
> > > have to be more careful to make sure DataReaders and Connections are
> > closed
> > > before they fall from our control (scope). This has other implications
> as
> > > well. Other applications competing for memory are also challenged as
the
> > > memory is being used and not released (immediately) by the .NET CLR
and
> > > until it's all allocated, the garbage collector won't release it. When
> > > memory is finally released, I expect you'll see a CPU spike as it
cleans
> > up
> > > the dormant objects. I expect that there's a way to limit the amount
of
> > > memory used by a .NET application.
> > > --
> > > William (Bill) Vaughn
> > > Author, Trainer, Mentor
> > > Microsoft Pacwest Regional Director
> > > Beta V Corporation
> > > "ADO and ADO.NET Examples and Best Practices for VB Programmers--2nd
> > > Edition" (ISBN: 1-893115-68-2)
> > > "ADO.NET Examples and Best Practices for C# Programmers" (ISBN:
> > > 1-590590-12-0)

> > > www.betav.com

> > > Please reply only to the newsgroup so that others can benefit. When
> > posting,
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > ________________________________



> > > > You may not have a memory leak at all. DotNet garbage collection
works
> > > > differently than previous technologies. When references to an object
> > > become
> > > > 0, previously the object would be removed from memory immediately.
Now
> > the
> > > > object remains in memory for a time (depending on how much memory is
> > > > available to the system) and cleaned up later. This may give you the
> > > > impression that you're experiencing a memory leak, when there isn't
> one.

> > > > --
> > > > Kevin Spencer
> > > > Microsoft FrontPage MVP
> > > > Internet Programmer
> > > > For ASP Tutorials and Information -
> > > > http://www.takempis.com



> > > > > Hi,
> > > > >     I have a few classes that have ADO.NET functionality in them.
> > > > >     When I call the objs (my custom ones) form my ASP.NET or
VB.NET
> > > apps,
> > > > > the memory just goes up and up and up. I am guessing that I am not
> > > > closeing
> > > > > something.

> > > > >     I was under the impression that I could just do a obj =
Nothing
> > and
> > > > that
> > > > > would do the trick.
> > > > >     What should I be doing in the ADO.NET part and in the Class
> part?

> > > > > Thanks..
> > > > > George.



Sat, 19 Feb 2005 19:44:56 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. .NET RTM Crystal.NET memory leak

2. Interop memory leak with VB.NET to VC++

3. VB.NET Memory Leak continuation...

4. Memory leak in VB.Net

5. Memory leak with VB.NET and SQL

6. ADO.NET with ASP.NET using VB.NET

7. Memory not released with vb.net and cr.net

8. Memory leak in CR for .NET

9. ADO.Net to fetch ActiveDirectory this function bugs in Asp.net but works in Vb.n

10. what create table using ADO.NET to VB.NET

11. VB.Net, Classes and ADO.Net guidelines???

12. VB.Net => Ado.Net = Stored Procedure

 

 
Powered by phpBB® Forum Software