1. just use count(*) in the query with the given criteria, this results in total row number so I can easily calculate Offset and Limit for the Criteria to get a specified page
*pros*: easy and simple. works in my current project
*cons*: performance - doubling queries, some queries might contain searches....
2. use LargeSelect
*pros*: elegant, nice with searches... can store multiple pages in user.Temp. less queries to database
*cons*: having ~200-300 sessions at the time... I hope would be fine as well.
another problem is: returned rows correspond e.g. to messages in a discussion list. LargeSelect caches the results.... some users however simply click "refresh" to see if there is sth. new.... so a solution would be to set a timeout for LargeSelect to invalidate it.
generally: is it worth to use LargeSelect? what do you use?
Having written a significant portion of LargeSelect I am hardly likely to go for the first option :-)
The refresh issue is interesting in that it kind of goes against the grain of what LargeSelect does (i.e. it exists to cache results, but in this case you don't want to cache even a single page, or you only want to cache it for a small amount of time).
If you set the memoryPageLimit of your LargeSelect to 1 in the constructor and invoke invalidateResult() on your large select before retrieving the data then the query will be executed every time - you would effectively be running your first option, but with a few features provided by LargeSelect (note that you have to manage the page number around this or you will jump back to page 1 every time (perhaps a variation on invalidateResult() that does not reset the current page number might be useful for this)).
An idea of providing a timeout for the LargeSelect result set
is interesting because it would not only provide a potentialy
better solution for your reset problem (fewer database hits might result with a timeout of say 30 seconds and a memoryPageLimit of > 1 page), but it would also perhaps reduce the LargeSelect con factor that you list above - i.e. if the result sets were cleared after some delay then they would reduce the amount of session memory consumed by users that have one or more LargeSelects sitting in User.Temp.
I'll make a note to look into this, but a can't promise anything for the short to medium term as I am flat tack working on my applications at present.
HTH,
Scott
-- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
