Memory Leaks From Objects... 2

[mwolf00]

I'm trying to clean up massive amounts of code. The biggest problem that I'm having is pinpointing the cause of memory leaks. I'm pretty sure that the main cause is objects that are not killed correctly (or at all). In the following :

set cn = server.createObject("adodb.connection")
cn.open application("connStr")
set rs = cn.execute("SELECT field1 FROM table1")

rs.close
set rs = nothing
cn.close
set cn = nothing

I never use the line "rs.close". Is that a problem?

Can I say "set cn = nothing" if I don't close it (I've never tried that and I thought that it would throw an error).

If I don't explicitly close an object, will it be closed when I set it equal to nothing?

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook

 

[DotNetGnat]

Its a good practice to explicitly close the object and then set it to nothing...

-DNG

 

[DotNetGnat]

from a online resource:

A connection is opened underneath your Command object and it is released when the Command goes out of scope at the end of the page. If you want to release the Connection you can either set the Command object to reference Nothing as in:


Set cmd = Nothing

Or, you could close the connection by closing the Active connection as in:

cmd.ActiveConnection.Close

You should know that if you are using Connection Pooling, the REAL underlying connection may have been opened before you run this page of code, and it hangs around after you leave the page. See the Active Server Pages documentation for details.
Other Tips With Connections:

Use a Connection variable, instead of a Connection string as the ActiveConnection for Commands. By using a Connection variable, you're calling an existing connection. If you use a string you are creating a new connection for the command.

Clean up after yourself. Close Active Connections when you are done with them. You should also explicitly Close a connection when you are done with the connection and it is no longer needed. A connection is closed when it goes out of scope (when it's apparent you no longer need it). You can proactively call Close when you know that you no longer need a connection to free up resources before it goes out of scope.

-DNG

 

[DotNetGnat]

one more resource for you:

http://www.4guysfromrolla.com/webtech/060999-2.shtml

-DNG

 

[mwolf00]

OMG! - Do I need to close a recordset before I use it again!

set cn = server.createObject("adodb.connection")
cn.open application("connStr")
set rs = cn.execute("SELECT field1 FROM table1")
do while not rs.eof
  rs.movenext
loop

[blue][b]do I need to issue a close command here?[/b][/blue]

set rs = cn.execute("SELECT field2 FROM table2")
do while not rs.eof
  rs.movenext
loop

rs.close
set rs = nothing
cn.close
set cn = nothing

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook

 

[Tarwn]

I wouldn't think so. The act of setting an object to nothing is basically the same as pointing your variable (reference, pointer, etc) to another object so that nothing will be referencing the object anymore and it will be destroyed. By setting your recordset variable to another object it should be treated exactly the same as if you had set it to nothing, at least from the perspective of your first recordset.


Than again it is Microsoft, who knows what black magic hackery is going on in there (sorry, bad response with .Net 2 recently).

-T

 

[Tarwn]

edit --- previous post was suppose to say "bad experience" not "bad response"....too little coffee

 

[mwolf00]

Thanks for the answer Tarwn. I've been looking for a while and no one ever addresses it.

Any insite into the implicit close command when you set an object = nothing? I'm guessing that I shouldn't depend on it.

It still doesn't make sense that I'm suddenly having such a large leak problem on a site that's essentially been running for years without the problem...

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook

 

[Tarwn]

Setting your variable to nothing doesn't interact with the object, so the recordset object doesn't cange state just because you dereferenced it. OTOH, it is possible the the destructor for that object calls the close method. Though ifthat were the case then I am guessing there wouldn't be any concerns about the need for losing the object and dereferencing it because it would do it on it's own.

-T

 

[Sheco]

COM objects are destroyed when their reference counter reaches zero on all interfaces but:

1. Right or wrong, many VB programmers distrust that this will *actually* happen, perpahs because of the confusing persistance of VB forms variables where you think it is out of scope but it isnt.
2. With ASP on IIS, there is an ADO connection pool operating below the page code that keeps closed connections open for reuse.
3. No need to keep an object reference beyond the point you intend to use it...might as well free the resources... same logic applies to keeping the connection open.
4. Some prefer to do this as matter of style.
5. Java encourage explicitly freeing objects.

 

[mwolf00]

Sheco,

I realize that the connections remain for reuse and that connection pooling is supposed to be the best use of system resources. How much overhead can this cause? I'd have a hard time believing that it would be more than 1M. Yesterday, the site used about 200M of memory that it never released! No wonder the IT department hates me!

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook