If i have large amount of records to be returnd
to web client, do you have sugestions for me?

1. caching in server or client better?
2. like search engines behavor
3. does weblogic have this cache limits?
4. Will it effect server performance?

i think caching is not a great idea anyway, whether its on the server or client. let us suppose u have 500 records and and u want to display 20 records at a time, which actually translates into 25 pages of 20 records each.

most of the times user never cares to visit all the 25 pages. he might just visit one or more and then go back. in this case u will unnecessarily cahing so many records and holding up the memory.

it also depends if these records are some static piece of info which will be same for all the users - then u can think of caching them. but if these dynamic pages based on the user selection then caching is not at all recommended for the reasons mentioned above.

better wud be to hit the database on every set of record/page requested by the user

anyone has a different point of view

I think a good solution will be to cache only the primary keys on the servlet/JSP side. Then, when you want to go to some other page, you query the database only for the records that are shown on this page using the primary keys of this page.

Beware though that if you don't cache anything (or even if you cache only the primary keys), you can have phantom records that will appear (or disappear) when you change page. If you really need a snapshot of your data at some point in time, you will need to do some caching instead of going back to the database.

JS

U can try Using a Hashtable for generating key as the Query and resultSet as the Data


 I hope u got it but the expiration of the data must be made provision by LRU method so u can have good efficiency

 

Caching in the server side is not a good solution if you are expecting large number rows (consumes too much resource),plus if the client crashes you may have to hold the data for a period of time (till the session times out).
If you are unlucky enough you can bring down the server(let alone the performance) with an out of memory exception.

and even in the client side it may not be a good idea, because you may have to send all the data across the network.

storing the primary keys alone is a good idea.

Better still would be to fire the query so that you select only the block that is required (1st set would translate in to where key >1 & key<10. If you are using oracle you can make use of rowid with an orderby cluase).
when the client comes back you repeat the same but choose the different set of rows depending upon which block the client wants.
Executing the SQLs each time will be slower than caching them, but you are atleast not running the risk of eating up memory when too many clients connect.