Dispose pattern in ASP.NET pages

  • Thread starter Thread starter mircu
  • Start date Start date
M

mircu

Hi,
I'm using managed wrappers that contain unmanaged code in my web pages.
As I have some problems with memory (the memory grows and is not
returned to the OS) though I delete unmanaged c++ objects in destructors
I want to explicitly destroy objects using Dispose. But the problem is
when to call it? There is no event telling the user is leaving a page to
put in it code which disposes the objects.
Thanks in advance.

Regrads,
Mircu
 
Hi Mircu:

Your ASPX page does not stay 'running' while the client displays the
page. As soon as the response is complete the runtime is free to clean
everything up associated with the request, including the page object
itself. Even if the client were to somehow notify the server that it
is navigating away from a page, your ASPX page that processed the
request would be long gone.

Manish has some good advice, which is create and dispose the object
with resources as soon as possible.

If the object has to be around for several events (i.e. if you would
use it from Page_Load and then some Button click events), you could
always hook the Unload event of the Page and call Dispose on your
object from there.

HTH,
 
U¿ytkownik Scott Allen napisa³:
Your ASPX page does not stay 'running' while the client displays the
page. As soon as the response is complete the runtime is free to clean
everything up associated with the request, including the page object
itself. Even if the client were to somehow notify the server that it
is navigating away from a page, your ASPX page that processed the
request would be long gone.

I knew that after displaying the page the processing is completed on the
server. But as you pointed out, my object must live between postbacks.
When exactly the Unload event is called? If it is as you say it'd be
fine to dispose objects there.

Regrads,
Mircu
 
Użytkownik Manish Jadhav napisał:
I am assuming that's your's is a web application. In that case it is always better to create the object, use it, display whatever information you need to (on your web page) and immediately dispose off the object.

Yes, you're right its a web application. I'd like to dispose objects as
early as possible but if the object must live between postbacs (eg. it's
bound to a datagrid) it isn't clear when it will be disposed.

Regards,
Mircu
 
Hi Mircu,

If you have to keep the object around then Unload will not be of help.
Unload will happen after request processing completes. So how are you
keeping a reference around between postbacks? Keeping it in the
Session or Cache?

--s
 
U¿ytkownik Scott Allen napisa³:
If you have to keep the object around then Unload will not be of help.
Unload will happen after request processing completes. So how are you
keeping a reference around between postbacks? Keeping it in the
Session or Cache?

I keep them in the Session and when the user exits the page clicking
'Close' button or others I remove it from the Session if necessary. Hmm,
should it help if I call Dispose before removing from the session?

BTW I know that storing objects in the Session isn't good. I'm thinking
on implementing automatic object removing from the Session. The plan is
to have a structure to remember what objects are needed in the session
for specified page, and on every request test what page is called and
then remove unnecessary objects from the Session.

Regards,
Mircu
 
mircu said:
U¿ytkownik Scott Allen napisa³:

I keep them in the Session and when the user exits the page clicking
'Close' button or others I remove it from the Session if necessary. Hmm,
should it help if I call Dispose before removing from the session?

I'd call Dispose after removing it from Session.
BTW I know that storing objects in the Session isn't good.

This is ASP.NET, not ASP. In general, it's perfectly fine to store objects
in Session.
I'm thinking
on implementing automatic object removing from the Session. The plan is
to have a structure to remember what objects are needed in the session
for specified page, and on every request test what page is called and
then remove unnecessary objects from the Session.

This is very error-prone. A program shouldn't have to know details of how it
is programmed.

Instead, how about handing Session_End in global.asax, removing everything
from Session, and testing each one to see if it implements IDisposable. If
it does, call its Dispose method.
 
U¿ytkownik John Saunders napisa³:
Instead, how about handing Session_End in global.asax, removing everything
from Session, and testing each one to see if it implements IDisposable. If
it does, call its Dispose method.

Most of the objects I put in the Session are used only in one page and
they are accessed in postbacks. In that case removing objects in
Session_End is too late because it would be fired not before the user
session ends. But your idea - testing if IDisposable is implemented and
then calling Dispose is nice. Thanks.

Regards,
Mircu
 
mircu said:
U¿ytkownik John Saunders napisa³:


Most of the objects I put in the Session are used only in one page and
they are accessed in postbacks. In that case removing objects in
Session_End is too late because it would be fired not before the user
session ends. But your idea - testing if IDisposable is implemented and
then calling Dispose is nice. Thanks.

If your page knows when there will no longer be any postbacks to it, then
you could remove the items when your page determines that it is done.

I'm concerned about what would happen if the user used the Back button in
his browser. Your page could be in the middle of a sequence of postbacks,
expecting to find Session state, only it's been removed. You may have to
deal with that situation.
 
U¿ytkownik John Saunders napisa³:
If your page knows when there will no longer be any postbacks to it, then
you could remove the items when your page determines that it is done.

When the user clicks only buttons it's ok I can determine if it's done.
Worse is when the user exits page by specifying new url in the address bar.
I'm concerned about what would happen if the user used the Back button in
his browser. Your page could be in the middle of a sequence of postbacks,
expecting to find Session state, only it's been removed. You may have to
deal with that situation.

Yes, it's a problem and therefore I think of implementing someting to
automatically clean Session.

Regards,
Mircu
 
Back
Top