ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Johnson" <johnson.jam...@gmail.com>
Subject Re: Caching by pre-loading
Date Fri, 05 Jan 2007 17:22:40 GMT
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 <Christian.Poitras@ircm.qc.ca> 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:johnson.james2@gmail.com]
> *Sent:* Thursday, 04 January 2007 19:32
> *To:* user-java@ibatis.apache.org
> *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 <jeffgbutler@gmail.com> 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 <johnson.james2@gmail.com > 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.
> > >
> >
> >
>

Mime
View raw message