469,270 Members | 1,583 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,270 developers. It's quick & easy.

ASP - Terminating objects in memory

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

Jul 26 '06 #1
8 1863

"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.
Jul 27 '06 #2

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

Jul 27 '06 #3
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"
Jul 27 '06 #4

"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

Jul 27 '06 #5
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


Jul 27 '06 #6

"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


Jul 28 '06 #7
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



Jul 30 '06 #8

"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






Jul 31 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Paul Rubin | last post: by
1 post views Thread by Earl Eiland | last post: by
1 post views Thread by Tony | last post: by
9 posts views Thread by cppaddict | last post: by
100 posts views Thread by E. Robert Tisdale | last post: by
5 posts views Thread by Xarky | last post: by
8 posts views Thread by vvenk | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.