Cache use your request (and parameters) to save results. In case1, the saved result is one query matching the complete List<User>. When querying 'select * from employees where id=#id#' it cannot match query 'select * from employees' and the cache is not used. But if you query 'select * from employees where id=#id#' twice for users 1 to 10, the cache'll be used on second set of queries. In case2, the saved result is a bunch of query 'select * from employees where id=#id#' matching a single user. When querying 'select * from employees where id=#id#', the cache always works (as long a size is at least equal to the number of users you have). Caching does not try to interpret your sql or to guess what your trying to do. To achive such a goal, you need to program a cache yourself. Christian
________________________________ From: James Johnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 10 January 2007 12:12 To: user-java Subject: Caching Performance First approach: At app startup, I ran a query 'select * from employees' and cached all results (4000 rows). Then, I later access the cache by issuing 'select * from employees' again. The results are put into a map, and I get from the map a subset of the employees (1 to 10). Second approach: At app startup, I ran queries 'select * from employees where id=#id#' for all id's and cached them (i.e. all employess, 4000 rows). Then, I later access the cache by issuing 'select * from employees where id=#id#' for the employees (1 to 10) that I want. The metrics that I collected suggest that the second approach is a faster way of getting the employees (1 to 10) from the cache. Does this make sense? If so, can someone explain why that is the case? Thanks.
