Werner Punz wrote the following on 7/28/2005 11:46 AM:

There are some ways to handle this
a) You can dump anything into the session, which means you run into memory problems in the long run.

I use this solution and have yet to run into any sort of memory problems. Resources aren't 'that' expensive. Use the Session unless you find out you have performance issues.


b) you can put everything into hidden fields, which means you have myriads of hidden fields, which is slow and error prone to implement.

Maintenance nightmare.


c) You can try to add the stuff manually to the session and remove it later, which also is problematic in case of an error because then you have a mem leak caused, by a tangeling object in the session.

Above is talked about a lot on this list, but have yet to see a good implementation of it. I think it will be a difficult undertaking and could be a pain to configure. The control mechanism will have to figure out when and what to clear out of the Session at any given time. Say the user clicks on some other link.. that path(I'm assuming) will have to be checked to see if it's safe to remove x number of Session based objects. I've tossed around with the idea of associating certain 'paths' with a Session scoped action form and as each request passes through the main filter it would check the path and based on the path and certain objects in scope certain ones would be be removed. Seemed like such a pain though so I gave up before I even really started on it:)


--
Rick

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to