struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Ramon Diaz" <jose.d...@aranzadi.es>
Subject RE: Session size
Date Fri, 28 May 2004 05:59:32 GMT

We use this approach :
 As our application is very heavy loaded data (?) (a lot of screens have
alot of data, recordsets or huge texts), the Actions do NOT take the data
itself to put it nor session neither request.
The actions just modify the model to represent the new situation after a
user submit, and of course fordwards to the next JSP.
The JSP always access the model (only getter methods of the model) throug
our own tags to access the data needed. As the model is in the correct state
because of the action, the data is ok. So, as you can imagine, we do cache
data in DAO layer if needed, or in application scope it the data is shared
beetwen all the users.
Regards

   Jose R. Díaz

> -----Mensaje original-----
> De: Hookom, Jacob [mailto:Jacob.Hookom@redline.mckhboc.com]
> Enviado el: jueves, 27 de mayo de 2004 21:08
> Para: 'Struts Users Mailing List'
> Asunto: RE: Session size
>
>
> We've noticed in our enterprise deployments that we aren't
> utilizing the
> session enough... so there's no straight rule of thumb. It
> depends on how
> many users you have and how much memory/processor.
>
> We have the opposite problem where we are scoping too much
> stuff at the
> request and refetching it all the time, causing high
> processor usage and low
> memory consumption.
>
>
> -----Original Message-----
> From: Riyad Kalla [mailto:rsk@email.arizona.edu]
> Sent: Thursday, May 27, 2004 12:11 PM
> To: Struts Users Mailing List
> Subject: Re: Session size
>
> On Thursday 27 May 2004 09:53 am, Zhang, Larry (L.) wrote:
> > It sounds like very promising to me. The only consideration is that
> caching
> > those objects may cause another issue of usage of the
> memory. And also
> when
>
> Yes absolutely a concern, which is where you can tune how big
> your cache for
>
> DAO is. For example, UserRoles might be cheap/small objects,
> so your cache
> can be 100 units big, and your Users might be expensive/huge
> objects, so
> your
> cache only holds 20 units... something like that.
>
> Doing analysis on the memory requirements is a good idea.
> Considering that
> your users (200 of them) takes up 8k, that's nothing to a
> server with 2Gig
> of
> ram... so you could probably increase this to hold a cache of
> 100s of users.
>
> > the tree is changed (by deleting/transferred one employee
> from the tree)
> we
> > need to somehow validate/rebuild the cached list of objects.
>
> Hmm yes, if its important to keep the cache as intact as
> possible, then
> applying logic during table mutations is important.
>
> >
> > Is this approach sometimes called object pool?
>
> Object pooling is more generic. The idea being pooling is to
> store objects
> for
> reuse usually in the pattern of (1) reinitialize/clear object
> then (2)
> repopulate and use it (3) return it to the pool.
>
> Where in this case we want to create our objects, and then
> keep them in
> their
> same state before reusing them, we aren't really returning
> them to a 'pool'
> to be pulled out again and reinitialized.
>
> Specifically, when we read in a UserDTO lets say (Data
> Transfer Object), we
> want to keep his data untouched (e.g. Name="Bob", Age="32"). After
> displaying
> Bob's data, we don't return his object to a pool, we keep it
> around in a
> cache, so when someone says "Hey give me Bob's record" we've
> got it handy
> without hitting the database again.
>
> But yes, caching and pooling are definately in the same family of
> 'strategies'
> for program performance.
>
> Best,
> Riyad
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message