It sounds to me like a deficiency in the tag lib. I would say that maintaining page information in the session scope is a bad idea if you are only storing partial results. If you are placing your whole result into the session then you can use a system like mine that reads the list from the session and splits it according to the page you are one. This maintains the users results without hitting the database each time.
So the process would go something like this: 1) Initial call on database 2) Translate resultsSet to a list of beans 3) Store the list of beans in the session 4) maintain page references in you next, page numbers, and previous (ie <<previous 1 2 3 4 next>>) 5) when a new page is clicked an action is called 6) the session stored list is retrieved in the action and the appropriate results are prepared for that page 7) the results are passed to the page as a request attribute. 8) user standard taglibs to display results and set up pagination 6) if a user does a new search then the database is polled again and a new result populates the session scope bean list. Depending on the potential size of your results there are some other techniques that you can implement to avoid an enormous list from existing in each users session scope. But, that is another topic. Brandon Goodin Phase Web and Multimedia P(406)862-2245 F(406)862-0354 http://www.phase.ws -----Original Message----- From: Chen, Dean (Zhun) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 11:58 AM To: 'Struts Users Mailing List' Subject: RE: pagination & session scope issue I'm using Lists that represent recordsets. The resultsets per request changes frequently. Dean Chen -----Original Message----- From: Brandon Goodin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 12:43 PM To: Struts Users Mailing List Subject: RE: pagination & session scope issue It is a jvm level thing. I have a cache that is instantiated at app startup. It works in a shared hosting environment too becuz each app runs it's own classLoader. When the app needs to lookup data it looks in the cache first under a key that is determined by you (usually a unique id that is produced by a combination of lookup parameters). If the key is there then it pulls the cached results(A Bean List) from it. It sounds like you may need something that is more like a persistence layer. Are you caching recordsets or Lists? Brandon Goodin Phase Web and Multimedia P(406)862-2245 F(406)862-0354 http://www.phase.ws -----Original Message----- From: Chen, Dean (Zhun) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 10:19 AM To: 'Struts Users Mailing List' Subject: RE: pagination & session scope issue When u cache it, do you cache it in session scope or in application scope? If you cache it in application scope, how does each form know which cache to use. I don't have a problem paginating... but the combination of session scope & pagination is a problem. Thanks Dean Chen -----Original Message----- From: Brandon Goodin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 12:06 PM To: Struts Users Mailing List Subject: RE: pagination & session scope issue if your data doesn't need to be live all the time... cache it and set an appropriate timeout. I wrote a simple caching mechanism that works great. This will reduce database lookups then you can create your pagination on the backend with Some classes. I have a set of classes i called Scroller,ScrollerBean, and ScrollerPageBean. The Scroller handles the splitting up of the List according to the page size specified and the size of the list passed and handles all the logic for determing the values that are stored in the ScrollerBean and ScrollerPageBean. The ScrollerBean holds all the values for the actual List, pageNumberList, next, nextPage, previous, previousPage, resultSize, etc. The ScrollerPageBean holds data specific to each page (i.e. pageLabel, pageValue, isSelected). Oh, also the Scroller does not return the whole List of objects to the page. It trims it down to the appropriate subList of the cached results. Scroller - populates ScrollerBean and ScrollerPageBean ScrollerBean - contains shared values for paging and contains a collection of ScrollerPageBeans properties: * int next - nextPage Number * boolean isNext - is there a next page * int previous - previous Page number * boolean isPrevious - is there a previous page * resultSize - this holds the total result size of the initial result set * List objects - A list of beans usually generated from a recordset to bean list translation * List scrollerPageBeans - A list of page values for generation of page list (ex 1 2 3 4) ScrollerPageBean - contains page specific paging values * int pageNum - array location of page Number to be passed back when the page is selected * int currPage - viewable page number (pageNum +1) so if pageNum is 0 (the index in the List) then the currPage would be 1 * boolean selected - a boolean indicating if this is the current page being viewed. All of this is then passed to the page where you can easily use tag libs to produce a page list. Brandon Goodin Phase Web and Multimedia P(406)862-2245 F(406)862-0354 http://www.phase.ws -----Original Message----- From: Chen, Dean (Zhun) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 9:46 AM To: 'Struts Users Mailing List' Subject: pagination & session scope issue Hi, I'm currently using Pager from JSPTags.com to do pagination. However, I'm running into problems because it requires the data to be kept in session scope. Basically the problem is that if 2 windows for a single application are open, the pagination mechanism fails because it uses the latest data in session scope. Is there a way around this besides going back to the database for every pagination? How does big websites like amazon, google, yahoo solve this problem?? Thanks a lot. Dean Chen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
