Disposing of Object and/or Components, Clarification Needed 2

[jmeckley]

In working with ASP.Net I can create objects and load them into memory to be used by controls on the screen. What about removing them when you are finished with them. The help files lead me to believe this is an automatic process done by the CLR.

Is this true, or do I need to include code in my functions and sub routines to free up resources? I know with projects in the past I would always need to include 2 lines of code when working with record sets.
RecordSet.Close
Set RecordSet = Nothing

Along these same lines, are the data sets and data views stored in memory on the clients machine, or on the web server. It would seem to me it would be created on the users machine to take advantage of network resources. But I want to be sure.

Thank you in advance

Jason Meckley
Database Analyst
WITF

 

[jfrost10]

Hey Jason,

All objects created with asp.net are stored on the web server: datasets, dataviews, etc.

In a nutshell, here's how garbage collection works:

There's a managed stack that holds all the various objects in memory. As objects become unused (either by falling out of scope, or by being set to = Nothing) they are flagged as such in the stack. When the stack hits its memory limit, it performs garbage collection, which is basically going through and deleting all the flagged objects.

Its always a good idea to set your objects to = Nothing whenever you're done with them.

hth

D'Arcy

 

[link9]

That's not exactly accurate.

The managed heap is where objects are stored.

But there's also a managed stack, which is where the references (or pointers) to those objects are stored, and that's what your variable points to.

So when you declare an object, a range of addresses on the heap is allocated for your object, and a variable reference to those addresses is placed in the stack, and that reference is returned to your code. So you never have direct access to the heap, only the reference.

Objects on the managed heap are not "flagged" as unused. What happens is that their references (on the stack) either (a) go out of scope or (b) are set to null.

Then, when the garbage collector decides to run (which no one but MS really knows when that is), it goes through the heap looking for any addresses that don't have references on the stack. Those objects are cleaned out, and the heap is compacted.

Is it a good idea to set your references to null when you're done with them? Sure, it's good programming practice.

The ones you need to worry about are your "unmanaged" resources, such as database connections and file handles and the like. The reason that you need to release those, however, might not be what you'd expect.

It's not to make your code run faster. It's to free those guys up for other processes to use. Database connections go back to the pool, and files are returned to a ready state.

Will your code run faster if you are very clean in your practices? Again, you might be surprised to know that there is alot of argument on this subject. Some people say "Let the garbage collector do his business, and you worry about yours", and others say "Absolutely."

Personally, I don't know if it will or not, but in the meantime, I'll stay in the "clean camp", and would suggest that to anyone else, as well, just for good programming practice. Heaven forbid you find yourself in the unmanaged world again one day and you're not used to cleaning up after yourself.

Anyway... my two cents.
**kachink**

The answer to getting answered -- faq855-2992

 

[link9]

One other things about "Dispose"

This method was intended as a method for an object to release the references to those "unmanaged" resources that I was speaking of, so if you have unmanaged resources in a class, then consider implementing IDisposable and making sure it's called whenever an instance is done working.

Setting the reference = null when you're through is NOT the same thing, and will cause those unmanaged resources to remain on the heap longer before being released back from whence they came. Garbage collection will eventually get around to it, but best not to wait on those types of resources.


paul

The answer to getting answered -- faq855-2992

 

[jfrost10]

Hey...its been a long week...cut me some slack


momma always did like Paul best...

D

 

[jmeckley]

Wow! thanks for the information. Now I just need to put theory into practice. I find it is a good habit to manually remove objects from memory. It also makes it much easier to know what is going on in the code, instead of assuming the system is done with it.

From what I can tell when I finish with a object (connection, commmand, adapter, dataset, dataview, or other class) I should add 2 lines of code for each object:
object.dispose
object = nothing
Is this the correct syntax, or am I using them incorrectly? The code compiled and ran without error so I fiugre it did. Once this is done the references are flagged and the system will clean them out, correct?

Jason Meckley
Database Analyst
WITF

 

[chiph]

Jason -

That's correct - call Dispose (which cleans up the unmanaged resources), then set to Nothing afterwards if you're a neat-nik.

It is possible to cause a garbage collection cycle to run yourself by calling GC(x) where x is a generation, but it's generally considered bad practice, as the Microsoft heuristic is actually very good.

When people forget to call Dispose on things like File handles, etc. you'll see them post things like "It's saying the file is already open, but no one else is using it!" -- it's because a GC hasn't run yet, and so .NET still has the file locked.

Chip H.