How An ASP.NET PostBack Can Cause A Memory Leak
In my previous post How An ASP.NET DataBind Can Cause A Memory Leak, I talked about how I suffered from serious memory leaks in my current project, because of some user control not being disposed when doing manual databinding multiple times.
After being really happy about my tedious quest being finished to fix the problems, I today noticed the memory leak still occurred in exact the same location, but when using the functionalitity in another way.
The case is still the same:
Page -> UserControl -> Repeater -> UserControl
So the loaded page of the scenario, contained a user control of our own. This user control had a repeater, repeating over the rows of a generic list, creating another UserControl for each found row.
Every row, rendered through the ASP.NET Repeater, has 2 buttons available:
- A button to edit the given row
- A button to delete the given row
The button to edit the given row is not giving me any problems. When I click it, the user gets redirected to the edit page and everything gets cleaned up pretty well.
The delete button on the other hand, is performing a postback on the same page, calling an event to handle the delete:
1 public void DeleteImageButton_Click(object sender, EventArgs e)
2 {
3 }
Ofcourse this delete event is doing the following stuff:
- Getting the row’s id from the CommandArgument
- Calling our business layer to delete the record
- Performing a databind to reflect the changes
It is the last action, which performs the databind, which is now triggering the memory leak … again.
The problem
By doing a postback when clicking the button, a new instance of my user control with all it’s needed resources is created.
Because I’m doing a DataBind() at the end of my “Action”, a second instance of the same user control with all it’s resources is created, leaving the first one undisposed forever.
The second one though, is being disposed properly and does not give me any problems.
The only explanation I would have for this kind of behaviour, is that it all happens inside one postback cycle.
Probably if a control is then created multiple times, only the last one gets disposed at the end of the cycle, leaving the other ones up to the Garbage Collector.
In our case the Garbage Collector is not of any use, since the user control has references to other undiposed objects, causing all those objects to remain in memory and causing a memory leak in the end.
The solution
Well, to be honest I don’t know a proper solution right now and I will probably need some time to figure out a proper way to fix this.
If I add the databind, the application is suffering from a memory leak, which is totally unacceptable.
If I remove the databind, deleted records are still shown on my page, which is totally user unfriendly.
I’ll keep you posted if I find a proper solution, and I then hope ASP.NET is not going to disappoint me ever gain.