ASP - Terminating objects in memory

[Lauren the Ravishing]

Hi,

In ASP, is it absolutely necessary to set an object to Nothing after
being used?

set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?

I'm dealing with a large number of files with nested includes. There
are many places where I use the object, I want to avoid initializing
the object any more than necessary, and I want to change as few pages
as possible. The simplest way for me to do this is to not set the
object to nothing. Will ASP implicitly remove the object from memory,
or will I have a memory leak?

~ L

[Anthony Jones]

"Lauren the Ravishing" <la******************@yahoo.comwrote in message
news:11**********************@m79g2000cwm.googlegr oups.com...

Hi,

In ASP, is it absolutely necessary to set an object to Nothing after
being used?

set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?

I'm dealing with a large number of files with nested includes. There
are many places where I use the object, I want to avoid initializing
the object any more than necessary, and I want to change as few pages
as possible. The simplest way for me to do this is to not set the
object to nothing. Will ASP implicitly remove the object from memory,
or will I have a memory leak?

~ L

ASP will implicitly call the release method on any interface pointer
currently held by a variable when it passes out of scope. This includes
when the script has completed resulting in the script context being reset.

Not using set to nothings will not, of itself, introduce a memory leak.
However there is no harm in using set to nothing either and some developers
consider it good practice (I'm not one of them though).

Anthony.

[Mike Brind]

Anthony Jones wrote:

"Lauren the Ravishing" <la******************@yahoo.comwrote in message
news:11**********************@m79g2000cwm.googlegr oups.com...

Hi,

In ASP, is it absolutely necessary to set an object to Nothing after
being used?

set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?

I'm dealing with a large number of files with nested includes. There
are many places where I use the object, I want to avoid initializing
the object any more than necessary, and I want to change as few pages
as possible. The simplest way for me to do this is to not set the
object to nothing. Will ASP implicitly remove the object from memory,
or will I have a memory leak?

~ L

ASP will implicitly call the release method on any interface pointer
currently held by a variable when it passes out of scope. This includes
when the script has completed resulting in the script context being reset.

Not using set to nothings will not, of itself, introduce a memory leak.
However there is no harm in using set to nothing either and some developers
consider it good practice (I'm not one of them though).

Why is it considered "good practice" by some?

--
Mike Brind

[Bob Barrows [MVP]]

Mike Brind wrote:

Why is it considered "good practice" by some?

Some of the reasons I've seen cited include:

1. Being in control of when objects are created and released - this is the
one I used to see most often in the "x tips for writing code" lists I used
to read in books and on the web.The upshot being that one could not consider
oneself to be a "good" programmer if this level of control was not retained.
This tip was usually about the recommendation against using the VB "dim x as
new object" syntax, but many authors included the requirement to always
explicitly destroy objects when no longer needed. I read this so often that
it did become ingrained.
2. Self-documentation: it's easy to see when one is finished using the
object
3. Resource management: releasing large-footprint objects from memory at the
first opportunity can't be bad.
4. Various bugs related to the failure to set objects to nothing have been
documented - these bugs typically involve child objects where the order of
releasing them is important (DAO and ADO), and memory leaks have been
reported, to the point where IIS stops responding.
5. Distrust of the automatic garbage collector (GC) - given the existence of
the various bugs, distrust did develop and combined with the need for
control nentioned in 1, the use of the set x=nothing became ingrained for
many of us.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Anthony Jones]

"Mike Brind" <pa*******@hotmail.comwrote in message
news:11*********************@75g2000cwc.googlegrou ps.com...

>
Anthony Jones wrote:

"Lauren the Ravishing" <la******************@yahoo.comwrote in message
news:11**********************@m79g2000cwm.googlegr oups.com...

Hi,
>
In ASP, is it absolutely necessary to set an object to Nothing after
being used?
>
set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?
>
I'm dealing with a large number of files with nested includes. There
are many places where I use the object, I want to avoid initializing
the object any more than necessary, and I want to change as few pages
as possible. The simplest way for me to do this is to not set the
object to nothing. Will ASP implicitly remove the object from memory,
or will I have a memory leak?
>
~ L
>

ASP will implicitly call the release method on any interface pointer
currently held by a variable when it passes out of scope. This includes
when the script has completed resulting in the script context being

reset.

Not using set to nothings will not, of itself, introduce a memory leak.
However there is no harm in using set to nothing either and some

developers

consider it good practice (I'm not one of them though).

Why is it considered "good practice" by some?

I think Bob pretty much covered it. The main driver for this whole 'you
should set to nothing' business is bugs in the first versions of ADO. If you
didn't release references to related connection, command and recordset
object in a specific order you could leak memory. Whilst VB(5|6|A|Script)
guarantees to release out of scope references it doesn't guarantee the order
in which it will release them. So the workround to this bug was to release
them yourself in the order needed to avoid the affects of the bug.

This lead to a common myth that VB can't be trusted to release references so
therefore you must do them yourself.

>
--
Mike Brind

[Janette]

Hi,

So is the myth that vbscript can't be trusted in the order it releases
memory, and therefore having the potential to cause a memory leak, which can
bring IIS to a halt, likely to be still be an issue for vbscript running in
an ASP page in Windows 2000 in IIS 5?

If so, what kind of errors what you expect to get as IIS freezes up, and are
there any performance monitors that you could use to detect that it is
happening?

Thanks
Janette


"Anthony Jones" <An*@yadayadayada.comwrote in message
news:ej**************@TK2MSFTNGP04.phx.gbl...

>
"Mike Brind" <pa*******@hotmail.comwrote in message
news:11*********************@75g2000cwc.googlegrou ps.com...

>>
Anthony Jones wrote:

"Lauren the Ravishing" <la******************@yahoo.comwrote in
message
news:11**********************@m79g2000cwm.googlegr oups.com...
Hi,

In ASP, is it absolutely necessary to set an object to Nothing after
being used?

set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?

I'm dealing with a large number of files with nested includes. There
are many places where I use the object, I want to avoid initializing
the object any more than necessary, and I want to change as few pages
as possible. The simplest way for me to do this is to not set the
object to nothing. Will ASP implicitly remove the object from memory,
or will I have a memory leak?

~ L
ASP will implicitly call the release method on any interface pointer
currently held by a variable when it passes out of scope. This
includes
when the script has completed resulting in the script context being

reset.

>
Not using set to nothings will not, of itself, introduce a memory leak.
However there is no harm in using set to nothing either and some

developers

consider it good practice (I'm not one of them though).

Why is it considered "good practice" by some?

I think Bob pretty much covered it. The main driver for this whole 'you
should set to nothing' business is bugs in the first versions of ADO. If
you
didn't release references to related connection, command and recordset
object in a specific order you could leak memory. Whilst VB(5|6|A|Script)
guarantees to release out of scope references it doesn't guarantee the
order
in which it will release them. So the workround to this bug was to
release
them yourself in the order needed to avoid the affects of the bug.

This lead to a common myth that VB can't be trusted to release references
so
therefore you must do them yourself.

>>
--
Mike Brind

[Anthony Jones]

"Janette" <ni**@community.nospamwrote in message
news:OS****************@TK2MSFTNGP06.phx.gbl...

Hi,

So is the myth that vbscript can't be trusted in the order it releases
memory, and therefore having the potential to cause a memory leak, which

can

bring IIS to a halt, likely to be still be an issue for vbscript running

in

an ASP page in Windows 2000 in IIS 5?

Not quite sure what you are saying or asking.

The order in which memory itself is released is not going to cause a leak.
Bugs of this form are invariably found in the components being used by the
ASP pages rather than in ASP/VBScript itself.

If so, what kind of errors what you expect to get as IIS freezes up, and

are

there any performance monitors that you could use to detect that it is
happening?

Set your application protection to high (isolated)
Process -Virtual Bytes (Choose the DLLHOST instance that represents the
application that your having a problem)

If this continues to grow progressively then that would indicate a leaky
app.

This may also be useful:-

Asp Server Pages -Request Executing

If this grows it can show hung Requests once this uses up the available
threads the site will hang.
This is likely caused by using a COM component not designed for use in
unattended mutlithreaded apps.
For example a component which attempt to alert the user to problem via a
message box will just hang the thread.

>
Thanks
Janette


"Anthony Jones" <An*@yadayadayada.comwrote in message
news:ej**************@TK2MSFTNGP04.phx.gbl...

"Mike Brind" <pa*******@hotmail.comwrote in message
news:11*********************@75g2000cwc.googlegrou ps.com...

>
Anthony Jones wrote:
"Lauren the Ravishing" <la******************@yahoo.comwrote in
message
news:11**********************@m79g2000cwm.googlegr oups.com...
Hi,
>
In ASP, is it absolutely necessary to set an object to Nothing

after

being used?
>
set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?
>
I'm dealing with a large number of files with nested includes.

There

are many places where I use the object, I want to avoid

initializing

the object any more than necessary, and I want to change as few

pages

as possible. The simplest way for me to do this is to not set the
object to nothing. Will ASP implicitly remove the object from

memory,

or will I have a memory leak?
>
~ L
>

ASP will implicitly call the release method on any interface pointer
currently held by a variable when it passes out of scope. This
includes
when the script has completed resulting in the script context being

reset.

Not using set to nothings will not, of itself, introduce a memory

leak.

However there is no harm in using set to nothing either and some

developers

consider it good practice (I'm not one of them though).

Why is it considered "good practice" by some?

I think Bob pretty much covered it. The main driver for this whole 'you
should set to nothing' business is bugs in the first versions of ADO. If
you
didn't release references to related connection, command and recordset
object in a specific order you could leak memory. Whilst

VB(5|6|A|Script)

guarantees to release out of scope references it doesn't guarantee the
order
in which it will release them. So the workround to this bug was to
release
them yourself in the order needed to avoid the affects of the bug.

This lead to a common myth that VB can't be trusted to release

references

so
therefore you must do them yourself.

>
--
Mike Brind

[Janette]

Hi Anthony,

Thanks for the information. One more question, how do you identify what a
dllhost instance is associated with?

Thanks
Janette

"Anthony Jones" <An*@yadayadayada.comwrote in message
news:uN**************@TK2MSFTNGP02.phx.gbl...

>
"Janette" <ni**@community.nospamwrote in message
news:OS****************@TK2MSFTNGP06.phx.gbl...

>Hi,

So is the myth that vbscript can't be trusted in the order it releases
memory, and therefore having the potential to cause a memory leak, which

can

>bring IIS to a halt, likely to be still be an issue for vbscript running

in

>an ASP page in Windows 2000 in IIS 5?

Not quite sure what you are saying or asking.

The order in which memory itself is released is not going to cause a leak.
Bugs of this form are invariably found in the components being used by the
ASP pages rather than in ASP/VBScript itself.

>If so, what kind of errors what you expect to get as IIS freezes up, and

are

>there any performance monitors that you could use to detect that it is
happening?

Set your application protection to high (isolated)
Process -Virtual Bytes (Choose the DLLHOST instance that represents the
application that your having a problem)

If this continues to grow progressively then that would indicate a leaky
app.

This may also be useful:-

Asp Server Pages -Request Executing

If this grows it can show hung Requests once this uses up the available
threads the site will hang.
This is likely caused by using a COM component not designed for use in
unattended mutlithreaded apps.
For example a component which attempt to alert the user to problem via a
message box will just hang the thread.

>>
Thanks
Janette


"Anthony Jones" <An*@yadayadayada.comwrote in message
news:ej**************@TK2MSFTNGP04.phx.gbl...

>
"Mike Brind" <pa*******@hotmail.comwrote in message
news:11*********************@75g2000cwc.googlegrou ps.com...

Anthony Jones wrote:
"Lauren the Ravishing" <la******************@yahoo.comwrote in
message
news:11**********************@m79g2000cwm.googlegr oups.com...
Hi,

In ASP, is it absolutely necessary to set an object to Nothing

after

being used?

set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?

I'm dealing with a large number of files with nested includes.

There

are many places where I use the object, I want to avoid

initializing

the object any more than necessary, and I want to change as few

pages

as possible. The simplest way for me to do this is to not set the
object to nothing. Will ASP implicitly remove the object from

memory,

or will I have a memory leak?

~ L
ASP will implicitly call the release method on any interface pointer
currently held by a variable when it passes out of scope. This
includes
when the script has completed resulting in the script context being
reset.

Not using set to nothings will not, of itself, introduce a memory

leak.

However there is no harm in using set to nothing either and some
developers
consider it good practice (I'm not one of them though).

Why is it considered "good practice" by some?

I think Bob pretty much covered it. The main driver for this whole
'you
should set to nothing' business is bugs in the first versions of ADO.
If
you
didn't release references to related connection, command and recordset
object in a specific order you could leak memory. Whilst

VB(5|6|A|Script)

guarantees to release out of scope references it doesn't guarantee the
order
in which it will release them. So the workround to this bug was to
release
them yourself in the order needed to avoid the affects of the bug.

This lead to a common myth that VB can't be trusted to release

references

so
therefore you must do them yourself.


--
Mike Brind

[Anthony Jones]

"Janette" <ni**@community.nospamwrote in message
news:O7**************@TK2MSFTNGP06.phx.gbl...

Hi Anthony,

Thanks for the information. One more question, how do you identify what a
dllhost instance is associated with?

It's a bit of a messy. First fire up Component Services from Administrative
tools, expand the tree down to COM+ applications and select that node. In
the tool bar select Status View. The list of COM+ application names should
contain an application called IIS-{...} where the contents of {} is
recognizable to you as your application. (This assumes you have set
application protection to high). The PID column shows the process ID of the
DLLHOST.exe process that is running your web app.

In performance monitor add a counter: Choose the Process performance object,
select the ID Process counter (which is a static value that will match the
PID and select the first DLLHOST in the instances list. ID Process doesn't
match the PID delete the counter and add a counter for the next DLLHOST#1 in
the list and so on until find the one that has a matching PID. Now add the
counters you want to monitor against that instance.

Thanks
Janette

"Anthony Jones" <An*@yadayadayada.comwrote in message
news:uN**************@TK2MSFTNGP02.phx.gbl...

"Janette" <ni**@community.nospamwrote in message
news:OS****************@TK2MSFTNGP06.phx.gbl...

Hi,

So is the myth that vbscript can't be trusted in the order it releases
memory, and therefore having the potential to cause a memory leak,

which

can

bring IIS to a halt, likely to be still be an issue for vbscript

running

in

an ASP page in Windows 2000 in IIS 5?

Not quite sure what you are saying or asking.

The order in which memory itself is released is not going to cause a

leak.

Bugs of this form are invariably found in the components being used by

the

ASP pages rather than in ASP/VBScript itself.

If so, what kind of errors what you expect to get as IIS freezes up,

and

are

there any performance monitors that you could use to detect that it is
happening?

Set your application protection to high (isolated)
Process -Virtual Bytes (Choose the DLLHOST instance that represents

the

application that your having a problem)

If this continues to grow progressively then that would indicate a leaky
app.

This may also be useful:-

Asp Server Pages -Request Executing

If this grows it can show hung Requests once this uses up the available
threads the site will hang.
This is likely caused by using a COM component not designed for use in
unattended mutlithreaded apps.
For example a component which attempt to alert the user to problem via a
message box will just hang the thread.

>
Thanks
Janette


"Anthony Jones" <An*@yadayadayada.comwrote in message
news:ej**************@TK2MSFTNGP04.phx.gbl...

"Mike Brind" <pa*******@hotmail.comwrote in message
news:11*********************@75g2000cwc.googlegrou ps.com...

Anthony Jones wrote:
"Lauren the Ravishing" <la******************@yahoo.comwrote in
message
news:11**********************@m79g2000cwm.googlegr oups.com...
Hi,
>
In ASP, is it absolutely necessary to set an object to Nothing

after

being used?
>
set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?
>
I'm dealing with a large number of files with nested includes.

There

are many places where I use the object, I want to avoid

initializing

the object any more than necessary, and I want to change as few

pages

as possible. The simplest way for me to do this is to not set

the

object to nothing. Will ASP implicitly remove the object from

memory,

or will I have a memory leak?
>
~ L
>

ASP will implicitly call the release method on any interface

pointer

currently held by a variable when it passes out of scope. This
includes
when the script has completed resulting in the script context

being

reset.

Not using set to nothings will not, of itself, introduce a memory

leak.

However there is no harm in using set to nothing either and some
developers
consider it good practice (I'm not one of them though).

Why is it considered "good practice" by some?

I think Bob pretty much covered it. The main driver for this whole
'you
should set to nothing' business is bugs in the first versions of ADO.
If
you
didn't release references to related connection, command and

recordset

object in a specific order you could leak memory. Whilst

VB(5|6|A|Script)

guarantees to release out of scope references it doesn't guarantee

the

order
in which it will release them. So the workround to this bug was to
release
them yourself in the order needed to avoid the affects of the bug.

This lead to a common myth that VB can't be trusted to release

references

so
therefore you must do them yourself.


--
Mike Brind