Typically data from DB is retrieved once and stored on appserver side. But to the client it is given in smaller chunks. Say from the browser, you clicked to get list of products. At the server side all the products are retrieved from DB and the resultset is saved in some variable. Say there are 37 rows found and we have previously decided to display only 10 products per page. The client will get only 10 rows for display but the client also gets to know how many page fulls are there (in this example 4). In the browser the user will se 10 rows and some hyperlinks to get next set of data. When the user clicks on Next, the server receives the page number and it retrieves next 10 rows from the stored result set and returns those to client. If it was last page then for our example it will return 7 rows. So basically in this pattern the server gets all the data once, stores it locally and only a subset of the total data is returned to the client in one request. Does that help? -Roshan
Originally posted by Pradeep Bhat: Hi, How is the value list handler patters implemented in web sites. Do they retrieve all the rows from db at once or in sets. thanx pradeep
Hi, What if the serach returns some 10,000 rows of data. It is not possible to store so many results in app server memory . Is n't ? What surprises me is that this is a common problem but no solution has been found as yet .Why not have a design pattern for this problem. Is any one listening?
Frank Carver
Sheriff
Joined: Jan 07, 1999
Posts: 6913
posted
0
Well, you could store 10000 rows in the apserver memory, if they were not too large. However, there is a more inportant issue here. I have never yet seen a real user who needed or wanted to see 10000 rows of anything. It's way too much for a human to read through. If your query is returning 10000 rows, I believe that you should offer the user more ways to refine the query rather than presenting this huge and unworkable list, even split into pages. Just imagine if the only interface to the Big Moose Saloon were a single huge list of all the posts ever made! In this system we offer the users choices of refining their interest by general topic, grouping into conversation threads, ordering by the date a message was posted, lists of the most recent posts by particular users, or just today's posts. All of these empower the user to decide which data to look at. Usually the place to perform such refinement is in the database - it's what databases are best at! Placing such logic in the application server layer can be dangerous as well as unneeded.
Frank is right on target. The solution I suggested, we actually use. We provide the user filters using which he can refine his search. If does not use any filter, we give him a warning and if he still continues without using any filter we only store a predefined max rows in the result variable. Practically, a couple of thousand rows should not be a problem for a production server. But if queries can return hundreds of thousands of rows, the query most likely should be modified. -Roshan
Lavern Matthew
Ranch Hand
Joined: Jun 05, 2004
Posts: 38
posted
0
I am the owner of a sourceforge project names valuelist (valuelist.sf.net). I have implemented the basic ValueListHandler. To solve the problem above, I have an adapter that uses a Scrollable ResultSet. Which retreives on the data on the given page.
0
