I'll look into the partial preload idea (currently using LRU). Sounds like it could give the performance needed on common first requests. Thanks for the suggestion.
On 1/5/07, Poitras Christian <[EMAIL PROTECTED]> wrote:
Maybe you can just use LRU caching. If requests are often alike, you won't even need to question yourself as long as the cache size is large enough. If you must preload your employees, maybe running many "select * from employee where id=#id#" at startup with most used ids will give you better results. Christian ------------------------------ *From:* James Johnson [mailto:[EMAIL PROTECTED] *Sent:* Thursday, 04 January 2007 19:32 *To:* [email protected] *Subject:* Re: Caching by pre-loading Thanks for the quick response. "iBATIS caches by SQL statement". I thought that was the case. Thanks for confirming. I'm trying to just use iBatis caching. One way that I saw of accomplishing pre-loading was to issue the "select * from employee" at web application startup. Then, on each user request for an employee(s), I re-executed the "select * from employee". iBatis returns the cached results (I'm using a queryForMap("getAllEmployee", null, "id")). Then I get the employees of interest by using a get on the Map. However, except for the first user request of a given employee, metrics seem to show this to be slower than just querying "select * from employee where id=#id#" for each employee. Any ideas on how to use iBatis caching only and have the first response to an user being cached data (pre-loading) while having subsequent responses be at the speed of a cached "select * from employee where id=#id#"? Perhaps, it's a situation where the best of both worlds is not possible. On 1/4/07, Jeff Butler <[EMAIL PROTECTED]> wrote: > > iBATIS caches by SQL statement - your two statements are different, so > there is a cache miss. This also demonstrates a fundamental truth about > iBATIS - iBATIS doesn't know about object identity. So iBATIS would have no > way of looking through the first set of cached results to see if an object > from the second statement already is available. > > You could accomplish what you want by loading all the employees into > some cache that you manage - and then selecting individual employees from > your cache. Maybe your cache could just be a simple HashMap keyed by > employee id? > > Jeff Butler > > > > > > On 1/4/07, James Johnson <[EMAIL PROTECTED] > wrote: > > > > How does iBatis determine whether results are to be pulled from the > > cache or to be queried from the database? For instance, if I have a > > query like such: "select * from employee" and then follow-up with a second > > query of "select * from employee where id=1", the second query appears to > > hit the database instead of finding the employee object in the cache with > > id=1. Is there way to have iBatis get the object from the cached results of > > the 1st query? Both queries are in the same sqlMap xml have the same result > > map. > > > > I'm trying to pre-load all employees at web application start so that > > the first user request (for a given set of employees) doesn't take a > > hit on response time. Most user requests are for 1-10 employees. > > > > Thanks in advance. > > > >
