Cleaning up stale collections in Web Scenario

Cleaning up stale collections in Web Scenario

Old forum URL: forums.lhotka.net/forums/t/2928.aspx


Jav posted on Tuesday, May 22, 2007

In a WebForm the GridView is populated by a collection furnished by CslaDataSource.  Other than setting up the GridView's DataSourceId, I have no other handle to the Collection.  When the user closes the form, can I assume that the collection will somehow be disposed off also - or should I maintain a separate handle to the collection and do the disposing myself?

Will appreciate some insight.

Jav

RockfordLhotka replied on Tuesday, May 22, 2007

Remember that ASP.NET is stateless. So the data is gone from the server after each page request, unless you explicitly put the object into Session, Application, Caching or a Shared/static field.

If you do put the object into Session, there's an automatic timeout (default is 20 mins). If the user doesn't hit your site in 20 mins that Session object, and all the data it contains, is flushed.

So in general, no, you don't need to do anything to clean up after a collection.

But then I see you use the word "dispose". That implies that your object is holding an expensive system resource (file handle, db connection, graphics object, etc). If that is actually the case I'd first ask whether you are sane, because you should avoid doing that sort of thing Wink [;)]  But assuming you are sane, and have a good reason for holding an expensive resource, then yes, you absolutely MUST dispose of that type of object.

That type of object should never be put into Session, because you could end up holding the expensive resource for 20+ mins. That type of object should only be used within page scope (or preferably method scope) so you can dispose it as early as possible. Ideally you'd use it only within method scope, so you can use a using block.

But I strongly doubt that is your issue - I certainly hope not...

JoeFallon1 replied on Tuesday, May 22, 2007

Jav,

If you plan to sort and page the data in the grid using the collection data then you have to put the collection into Session while the user is performing these actions. When they navigate away from the page with the grid you can remove the collection from Session as they no longer need it. The advantage to this scenario is that you only fetch the collection once from the DB and then re-use while the user does paging and sorting. (Other alternatives exist - like fetching only the current set of pages needed for display purposes and always querying the DB to get a different set of pages.) But I am talking about the case where you have all of the data in hand.

Some things to be careful of - the user may not use your page controls to Navigate away from the page with the grid. They could click the Back button or something. You can consider writing a method that runs on each request to RemoveCollectionsFromState. You keep only the collection for the "current page" the user is on and remove all others. ( I am assuming these are ROCs and that you name them consistently so your general method can find them and remove them.)

Joe

 

Jav replied on Tuesday, May 22, 2007

Thanks Rocky, Thanks Joe,

Rocky, I was indeed using the word dispose in its English sense (as in throw away, get rid off, put in the trash) sense Big Smile [:D], as opposed to its Programming sense.  The collection in question is instantiated within a method and attached to the GridView.

Joe, thanks for your suggestions.  We used to have all those discussions in the old forum about how to design our objects, and I don't think I fully grasped Rocky's advice when he told us to design our objects to handle the job at hand instead of bloating them up to do ten things.  Working in the web environment has finally given me an appreciation of what he was saying.  I am actually beginning to enjoy trying to see how lean and mean I can make my classes. I know that you have been doing web development from the beginning and must be an expert at it.  With ASP 2.0, it finally seems to be coming of age.

Jav

Copyright (c) Marimer LLC