Memory Issues with ABAP WD in Portal

Question

Hi Team,
I have two Web Dynpro Applications running on the Portal. Lets say the user in the middle of one application and clicks on the menu URL of another application, the memory of the first application is still utilized in the background and not freed up. My specific questions:
1) Should we do something explicitly in our WDA application to cleanup the memory? If yes, how? (Should we use some kind of exit plug etc.) I don't know what event or plug gets triggered when a new application is activated on the portal.
2) Is there any profile parameter, Portal parameter or any kind of script/configuration we should write separately to free up the memory.
3) Should we do something on the portal side to take care of this.
4) Is there a best practice or design recommendation regarding this
Any pointers/help would be appreciated.
Regards

Answer 1

First WDA is stateful, so design apps and nested calls around this fact.
You can definitely clean out memory of unused tables.
See the FREE statement.
You can also try the SUSPEND and resume plugs.  Assume other tool can do
resume call. Special URL parameters required.  This might free memory as the context is rolled out.
It would be rolled back in when called back.  I would need to check that ROLL OUT takes place. See transaction STATTRACE and watch what happens when you call the suspend plug to confirm the roll out occurs.
Is the memory being used in ABAP or on the PORTAL ?
If it is in the portal this has nothing to do with WDA.
Perhaps the portal forum can help more there.
Best practice.
Yes dont use memory unnecessarily.
EG DATA statements for internal tables can have INITIAL size to avoid 16k allocations.
FREE Tables and other objects if no longer needed.
If you have MANY WDA apps all storing (caching ) the same data, use shared memory objects.  See Blogs and other SDN posts that explain how to write a shared memory objects in ABAP OO.  This is 1 object in memory that could have an attribute that was an internal table.
A nice way to 1 table and not 100s or 1000s depending on how many users concurrently access your app.
Cheers
Phil.