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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
