Dispose pattern in ASP.NET pages

[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

 

[Scott Allen]

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,

 

[mircu]

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

 

[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

 

[Scott Allen]

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

 

[mircu]

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

 

[John Saunders]

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.

 

[mircu]

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

 

[John Saunders]

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.

 

[mircu]

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

 

[eliza81]

Dispose pattern for .Net Applications

Dispose pattern is nothing new but a better approach of disposing managed as well as unmanaged objects. This has been referred by the MSDN and meant for a better architecture towards object disposal in .Net applications.

The backbone of .Net applications, the CLR, does not have any control over the unmanaged resources. It can’t dispose them automatically as it does for managed ones. Hence it needs to be done explicitly by the programmer.

The proposed architecture was given by the MSDN for a flawless design and to avoid memory leaks. It provides the derived classes a chance to dispose their unmanaged (also managed) resources, if they have.


Example:
Snippet 1:

public class BaseClass : IDisposable
{
bool isDisposed = false;
public BaseClass()
{
//
// TODO: Add constructor logic here
//
}

#region IDisposable Members

public void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}

public virtual void Dispose(bool doingDispose)
{
if (!this.isDisposed)
{
if (doingDispose)
{
//Release all managed resources
}
//Release all Unmanaged resources over here.
//So if doingDispose is FALSE, then only unmanaged resources will be released.
}
this.isDisposed = true;
}

//Destructor
~BaseClass()
{
this.Dispose(false);
}

#endregion
}

Snippet 2:

public class DerivedClass : BaseClass
{
private bool isDisposed = false;
public DerivedClass()
{
//
// TODO: Add constructor logic here
//
}

public override void Dispose(bool doingDispose)
{
if (!this.isDisposed)
{
if (doingDispose)
{
// Release the managed resources you added in
// this derived class here.
}
// Release the native unmanaged resources you added
// in this derived class here
}
}
}

Explanation:

1. The above example is the recommended design pattern for Disposing objects and has been implemented through out the .Net Framework.
2. Here the BaseClass has a virtual Dispose method which gives the DerivedClass a chance to dispose the unmanaged resources.
3. Again the virtual Dispose class gets executed in two scenarios with true and false parameters.
4. In normal scenario the Dispose methods gets executed with true. It happens when an instance calls the Dispose() method, which in turn calls the Dispose(true) method.
5. For false, the Dispose(false) is called only at runtime from the finalize block(destructor) and disposes only unmanaged resources

Hope this tip is useful.
Thanks