ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Poitras Christian" <Christian.Poit...@ircm.qc.ca>
Subject RE: Caching Performance
Date Wed, 10 Jan 2007 22:39:54 GMT
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:johnson.james2@gmail.com] 
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. 


Mime
View raw message