self servicing, llblgen pro v2 (Dec. build) .net 2

Hi, I have a page with about 10 datasource controls on, mostly used to populate dropdown lists, some with 50 or more records. If I use CacheLocation = ViewState then the page gets way too big (in the region of 800K) so I use CacheLocation=Session which means the page is only 100k at its max. There will only be 1 to 2 users of the system at a time so I have no problem with the amount of data going into the session memory.

However, the session variables are recreated every time the page is called (which will be many times during average usage as it is being used to edit product information for a large number of products). The session variables are given a different name every time so the session usage is growing and growing as all the old variables are still in there.

Is there a way to clear out the old session variables used to cache the datasource?

Thanks,

Darren.

Darren166 wrote:

self servicing, llblgen pro v2 (Dec. build) .net 2

Hi, I have a page with about 10 datasource controls on, mostly used to populate dropdown lists, some with 50 or more records. If I use CacheLocation = ViewState then the page gets way too big (in the region of 800K) so I use CacheLocation=Session which means the page is only 100k at its max. There will only be 1 to 2 users of the system at a time so I have no problem with the amount of data going into the session memory.

The viewstate is larger than the actual size it occupies, as the viewstate is a bin-> ascii converted string, so in memory the amount is smaller, also because in the session, real objects are stored, not serialized binary data.

However, the session variables are recreated every time the page is called (which will be many times during average usage as it is being used to edit product information for a large number of products). The session variables are given a different name every time so the session usage is growing and growing as all the old variables are still in there.

Hmm, you are absolutely right... I append a GUID every time the object is loaded, which is a bad thing.

I'll make sure this is corrected in the next build as this is a memory leak. I'll see if I can append the control ID to it instead.

Is there a way to clear out the old session variables used to cache the datasource? Thanks, Darren.

You can, clear all session variables starting with "__LLBLGENPRODATASOURCEDATA_". You can use the Keys property of the session object to obtain all keys inside the session.

Sorry for this inconvenience and thanks for pointing this out. These kind of things often go by unnoticed

Thanks Otis, glad I could help.

For anyone reading this in a similar predicament, I used the following code to clear up the old session variables;

for (int i = Session.Count-1; i > 0; i--)
{
   string strKeyName = Session.Contents.Keys[i];
   if (String.CompareOrdinal(strKeyName, 0, "__LLBLGENPRODATASOURCEDATA_", 0, 27) == 0)
   {
      Session.Remove(strKeyName);
   }            
}

Note a few things here; 1) I count down from session.count to 0 because each time you remove a session object the count decreases and this way we always stay at the last object. 2) I use compareordinal because it is very fast. 3) This should only be called when a page is first loaded and not on postback or you will eliminate the current datasource session objects (a bad thing!).

Darren.

Thanks for the workaround code

It's indeed a bigger problem. Per page and postbacks it's ok, but indeed if you navigate back/forth through pages, it's a problem as indeed it gets a new ID every time.

The solution is I think to use the name of the control on the page, as with that, every page usage will overwrite the previous usage. The problem THEN of course is to avoid reading old data in. So it will be a little trickier than initial anticipated.

It's fixed in the next build of the runtime lib (2.0.07.0219), which is released later today.

Otis wrote:

It's fixed in the next build of the runtime lib (2.0.07.0219), which is released later today.

Everything works as planned however if you load a datagrid (web) with the llblgen ds saving in session and then go to a new page with the same datasource name and then click the back button the first grid will bind the original datasource with the second pages data and will throw an exception (when you have specific columns defined). Is there an easy way to determine what cache object the ds will try to receive from session and test to make sure the correct one is being represented.

ARRGG. I just thought of something. If you use the same datasource control name across all of your pages and you are saving the session based on control name then if the user has two seperate pages up pulling from two seperate datasources it will throw an exception also. Which I just confirmed. The only way around it is to name all of the datasource controls differently for the entire project which sucks if you are trying to keep the pages internally similar to ease replication. All of my controls are named LLBLGenProDataSource2_1 and since I am using a masterpage it is getting the DefaultContent name from the content placeholder. Is there any other way around this? could you possibly add the page name to the session id along with teh control name so I don't run into this?

__LLBLGENPRODATASOURCEDATA_ctl00$DefaultContent$LLBLGenProDataSource2_1

Thanks, Brandt Beal

I suggest we use the control Id + the page name, instead of the control Id alone.

Walaa wrote:

I suggest we use the control Id + the page name, instead of the control Id alone.

That would make things alot better. I am assuming there is nothing I can do on my side to fix this before LLBLGen addresses the problem other than changing all the control names?

THis is the key we use in the latest build: dataStorageKey = "__LLBLGENPRODATASOURCEDATA" + base.UniqueID;

The UniqueID is the ID of the control on the page as given by ASP.NET, so this is unique per page.

Indeed, if you move from page to page, this can be a problem.

I'll see if I can obtain a solid page ID/name to embed in this name as well, so you won't run into the problem you ran into.

Though I've to see if I can determine if the page is a postback or not, because if the page isn't a postback, the control shouldn't obtain cached data, but simply init itself, which also should solve the problem.

Otis wrote:

THis is the key we use in the latest build: dataStorageKey = "__LLBLGENPRODATASOURCEDATA" + base.UniqueID;

The UniqueID is the ID of the control on the page as given by ASP.NET, so this is unique per page.

Indeed, if you move from page to page, this can be a problem.

I'll see if I can obtain a solid page ID/name to embed in this name as well, so you won't run into the problem you ran into.

Though I've to see if I can determine if the page is a postback or not, because if the page isn't a postback, the control shouldn't obtain cached data, but simply init itself, which also should solve the problem.

The UniqueID is created from that INamingContainer interface thingy (I believe) and since I am using a master page for all of my content pages and all of the llblgendatasource controls are named the same on each page it will generate the exact same identifier. Additionally if you hit the back button and then click a button it is still in post back mode for the page.

Brandt wrote:

Otis wrote:

THis is the key we use in the latest build: dataStorageKey = "__LLBLGENPRODATASOURCEDATA" + base.UniqueID;

The UniqueID is the ID of the control on the page as given by ASP.NET, so this is unique per page.

Indeed, if you move from page to page, this can be a problem.

I'll see if I can obtain a solid page ID/name to embed in this name as well, so you won't run into the problem you ran into.

Though I've to see if I can determine if the page is a postback or not, because if the page isn't a postback, the control shouldn't obtain cached data, but simply init itself, which also should solve the problem.

The UniqueID is created from that INamingContainer interface thingy (I believe) and since I am using a master page for all of my content pages and all of the llblgendatasource controls are named the same on each page it will generate the exact same identifier. Additionally if you hit the back button and then click a button it is still in post back mode for the page.

Good point. So a page-specific Id/name is mandatory for solving this. thanks for this info. I'll see what I can do to fix this a.s.a.p.

Otis wrote:

Brandt wrote:

Otis wrote:

THis is the key we use in the latest build: dataStorageKey = "__LLBLGENPRODATASOURCEDATA" + base.UniqueID;

The UniqueID is the ID of the control on the page as given by ASP.NET, so this is unique per page.

Indeed, if you move from page to page, this can be a problem.

I'll see if I can obtain a solid page ID/name to embed in this name as well, so you won't run into the problem you ran into.

Though I've to see if I can determine if the page is a postback or not, because if the page isn't a postback, the control shouldn't obtain cached data, but simply init itself, which also should solve the problem.

The UniqueID is created from that INamingContainer interface thingy (I believe) and since I am using a master page for all of my content pages and all of the llblgendatasource controls are named the same on each page it will generate the exact same identifier. Additionally if you hit the back button and then click a button it is still in post back mode for the page.

Good point. So a page-specific Id/name is mandatory for solving this. thanks for this info. I'll see what I can do to fix this a.s.a.p.

Thanks Otis. By the way your product is first class and has saved me an enormous amount of time over the last few weeks. Even though I only use about 10% of its functionality I will most definitely be using as the foundation for all my future projects. Now all you need to figure out is how to allow us to create tables and instanciate those entities at run time with out even knowing what the table structure is going to be :-).

Thanks for the feedback!

I've added the bindingcontainer name of the datasourcecontrol. This is normally the page, but it could be with masterpages that it is the container page name inside the masterpage, so it should work properly.

I've attached the new build (2.0.7.0405), which should fix this issue. could you test it for me please? Be SURE you're using this new build in your webapp, as asp.net sometimes doesn't update referenced assemblies in the bin folder.

Otis wrote:

Thanks for the feedback!

I've added the bindingcontainer name of the datasourcecontrol. This is normally the page, but it could be with masterpages that it is the container page name inside the masterpage, so it should work properly.

I've attached the new build (2.0.7.0405), which should fix this issue. could you test it for me please? Be SURE you're using this new build in your webapp, as asp.net sometimes doesn't update referenced assemblies in the bin folder.

Excellent. I just tested and it works perfectly! Thanks for the quick response and support.

OK! Thanks for testing