question..
A reader, July 08, 2004 - 4:43 pm UTC
"If you did it the "get 100 rows and cache it and keep the database connection
for as long as there are more rows" you'll end up eating gobs of memory "
Why do you need to keep the db connection if you maintain
data in your session ?
July 08, 2004 - 8:49 pm UTC
ahh, i overstated the problem -- i see they capped the result set at 100 rows -- and would thus be able to free the connection.
I made the assumption they fetched 100 rows - showed them 10 at a time and when they needed 101-110 -- they would go back to the database. if they needed that, they would have to grab the connection each time.
if they know "just 100 records or less" and are willing to do the state mgmt on the middle tier (making the middle tier bloated) -- then it might be ok. (still have the time out issue, reconnecting with your session state and so on but it doesn't affect the database)
if they need to keep the connection across many pages -- no way.
how would it be in case of thick client
Rakesh, July 08, 2004 - 6:03 pm UTC
Hi Tom
Thanks for your reply. How would the pagination strategy to use differ depending upon the client to use.
You had asked me for whether I was using a thick client or thin (client side html ).
Can you also give your perspective for the thick client scenario
Bye
Rakesh
July 08, 2004 - 9:01 pm UTC
if you were thick client and always connected, by all means, let the cursor cache the results for you (fetch 10, fetch next 10 and so on).
if not, use the pagination query I like to use for stateless connections on the web.
Some Inputs from my practical experience
Dhrubo, July 09, 2004 - 1:23 am UTC
Hi,
In a 3-tier application there are 3 ways(as i can see) one can achieve pagination :
1)Get all the data once and then page it as per user request
--> This method is deadly and i m frightened for those who do this.I have seen in my company a very experienced person who was not well familiar with J2EE used stateful session bean to cache data ... oh my god when load testing was done it broke down with 5 users.So this technique gets more and more dangeous as the data volume increases.Moreover it may so happen that with this method you don't even show the first page when the data volume increases.
2)The best approach rownum technique as prescribed by tom
3)Look ahead method - where u bring some more data not all ... now this some more is very dubious and requires more coding ...
In summary i prefer method 2