struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry Meadors" <>
Subject RE: Form data vs request attributes
Date Tue, 18 Nov 2003 23:51:26 GMT
The reason I don't do this is because if the form is in session scope,
it hangs around consuming memory until the session goes away. 

As a caching mechanism, this bites rocks, because it is cached for each
user. :-/

By putting this type of stuff in request scope instead of on the form,
it becomes transient regardless of where the form resides. But if you
use a DAO layer with caching (like iBATIS), one copy of this stuff can
be cached (globally) so you are not hitting the database all the time.


>>> 11/18/03 4:41 PM >>>
> From: Mainguy, Mike [] 
> Although, I don't really see a major problem with storing the 
> options in the form itself (just to make things simple).  
> Anybody have a compelling reason NOT to do this?
> i.e. I put my statesCollection as a property on my ActionForm 
> with a List datatype.  Then I can just use the form property to 
> populate my options.

Every time Struts instantiates your Form object, it also creates that
list of states.  If you have 'state' on more than one form, there's
another list, times how ever many users have forms going at any one

Since the list of states is unlikely to change, I think it makes more
sense to put the list in application scope (as a context parameter) and
have only one instance of it.

However, memory is cheap, so it's probably not going to matter where you
put it as long as you're happy with your decision.

Wendy Smoak
Applications Systems Analyst, Sr.
Arizona State University, PA, IRM 

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message