This may sound a very stupid query but nonetheless
The ValueListHandler pattern is suggested as a solution in J2EE to the problem of retrieving large amounts of data from a database by constantly querying the database.
Is there any reason why this pattern should not be adopted as a design strategy for a client server implementation not using EJB's
No reason, except that this pattern has serious problems when the result set is large, whether used by a stateful session EJB or not.
Imagine a query which selects 100,000 rows, or even 10,000. If the user views them 50 on each page, how many pages, on average, does a user page through before executing a different query? Rarely would users page past, say, page 5 or 10. So perhaps 95% of the data is retrieved from the database and cached locally, and never used. In this case frequent access to the database is a GOOD thing! A balance must be struck between pulling from the database just enough records each time to be useful, without retrieving too many.
I don't think Sun's pattern addresses the core issue it suggests in the Context of the pattern - "The number of items in the list is unknown and can be quite large in many instances".
There seem to be problems with all the options:
i) Query the database for each (small) page. Expensive in network traffic; users get a performance hit each time they move next;
ii) Execute the query once, cache the data on the server and pass back pages to the client when requested. Possibly huge result sets will cripple the server in terms of reading all the records from the ResultSet and cacheing them; most of the data is never used.
iii) Some sort of 'virtual paging' algorithm, a compromise between the two above, using either:
a)a scrollable result set, but the problem then is that clients hold onto Connection objects from the pool for a long time, which defeats the object of having a pool.
b)Executing the query each time 'next' or 'previous' is selected, with a modified WHERE clause to retrieve the next x records.
> iii) Some sort of 'virtual paging' algorithm, a
> compromise between the two above, using either:
> a)a scrollable result set, but the problem then is
> that clients hold onto Connection objects from the
> pool for a long time, which defeats the object of
> having a pool.
> b)Executing the query each time 'next' or 'previous'
> is selected, with a modified WHERE clause to retrieve
> the next x records.
Can we have some frwk like this:
Have a Page object with the page size as a parameter. And in every request fetch only those many records ( say 'X' many records)and push it to the client...since the fetch usually takes time can we have a parallel thread that will fetch the next X records while the client is viewing the first X records. I agree that the client may never go to the next page but if he does then he will get the reponse quickly since the cached results will what be displayed to him..and as he is viewing this page the next one is getting ready on the server...any comments on this!!!
