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 the tree is changed (by deleting/transferred one employee from the tree) we need to somehow validate/rebuild the cached list of objects.
Is this approach sometimes called object pool? Thanks. -----Original Message----- From: Riyad Kalla [mailto:[EMAIL PROTECTED] Sent: Thursday, May 27, 2004 12:25 PM To: Struts Users Mailing List Subject: Re: Session size Hmm, I should clarify what I meant: The DAO will be at the application scope, so if you cache say the last 50 queries, the cache is held at application scope. In your case, this will still help. Lets say you have 20 users all working on the site, they all hit their "Show employement Tree" page, and you hit the UserDAO.getEmploymentTreeForUserID(int userID) method for all 20 people with different ID's. That will perform 20 separate queries, cache the result, and return it. Now when all those users hit the refresh button on their web page, it hits your DAO again, the same method, with all 20 separate ID's again. But this time, all 20 of them are successful cache hits and are returned immediately. Now say users 1-5 log out and come back 2 hours later and check your employement tree page, IF their list had been stored in their sessions, that would require you to hit the DB again to reload the lists, but because your caching the results in your DAO itself, all of those 5 users that came back and check their employement tree, are getting all their results from the DAO's cache again since it was stored at the application level (the cache is still valid). The other sexy thing is that if someone calls UserDAO.removeUserByID(4) or something liek that, your DAO knows to either (a) aggressively invalid all the cache and have all caches rebuilt, OR (b) you could take some time to intelligently remove that user from all cached values if it was import to you to keep your caches full. It just gives you more options since all your cache building/invalidating occurs in the same DAO class, instead of needing to worry about synchronizing multiple resources and classes with eachother. Did that make sense? Best, Riyad On Thursday 27 May 2004 09:13 am, Zhang, Larry (L.) wrote: > In my case I have to keep the List in the session level instead of > application level since different user will have different list of > employees. > > -----Original Message----- > From: Riyad Kalla [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 27, 2004 11:53 AM > To: Struts Users Mailing List > Subject: Re: Session size > > > Mike, > Good suggestions. I was dealing with something like this recently and > decided that for me, adding caching at the DAO level: > > e.g. List userList = UserDAO.getAllUsers(); > > would offer the biggest performance benefit since it would be: > > (a) application wide, instead of per session > (b) returned Lists are 4-byte pointers to the actual list object cached in > the DAO > (c) The DAO itself handles all manipulation of those types, so it knows > when to invalid its own cache (on inserts/updates/removes) > > > What do people think about this strategy? (Before I spend a week > implementing it :) > > Best, > Riyad > > On Thursday 27 May 2004 08:49 am, Mike Zatko wrote: > > I personally think its too big. Large amounts of data like that should > > be put in request scope so that it gets flushed out of memory right > > away. If you need the data to be persistent through the user's session > > lifetime, mabye try serializing it to a database. Of course, different > > situations call for different solutions. Also, I would try and replace > > your Vector with a non-synchronized Collection like an ArrayList or > > LinkedList unless you have some sort of mutlithreaded access to this > > collection. > > > > Riyad Kalla wrote: > > >Larry, > > >Good question. I am curious what others think about this situation as > > > well. > > > > > >On Thursday 27 May 2004 08:24 am, Zhang, Larry (L.) wrote: > > >>It is apparent true that if the session size is big, the performance > > >> will be negatively affected. The question is that how to actively > > >> control the size of session. > > >> > > >>Let's discuss this question: > > >> > > >>I have a page which displays all the subordinates of a manager, for > > >> some reasons I want to create a List or a Vector containing all the > > >> subordinates and put this List or Vector to the session. Each element > > >> in the List or Vector is a Java object, Employee( each Employee object > > >> has 200 String attributes, among which 5 are needed to be displayed on > > >> the screen) > > >> > > >>A picture of this situation is: > > >> > > >> Vector allSubordinates = new Vector(); > > >> allSubordinates.add(Employee1); > > >> allSubordinates.add(Employee2); > > >> ....... > > >> > > >> allSubordinates.add(Employee1000); > > >> > > >> > > >>session.setAttribute("allSubordinates",allSubordinates); > > >> > > >>Do you think this actually makes the session very big? > > >> > > >> > > >>Then what will be the improvement of the following? Instead of add all > > >> the employee objects, we create a very small object called > > >> DisplayObject, which just contains the 5 attributes required on the > > >> screen. > > >> > > >> Vector allSubordinates = new Vector(); > > >> allSubordinates.add(DisplayObject1); > > >> allSubordinates.add(DisplayObject2); > > >> ....... > > >> > > >> allSubordinates.add(DisplayObject1000); > > >> > > >> > > >>session.setAttribute("allSubordinates",allSubordinates); > > >> > > >>Your sharing of opinion is appreciated! > > >> > > >>Thanks. > > >> > > >>Larry > > >> > > >> > > >> > > >>--------------------------------------------------------------------- > > >>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] > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- 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]
