Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 94061 invoked from network); 5 Jan 2007 13:43:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Jan 2007 13:43:51 -0000 Received: (qmail 10900 invoked by uid 500); 5 Jan 2007 13:43:52 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 10888 invoked by uid 500); 5 Jan 2007 13:43:52 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 10877 invoked by uid 99); 5 Jan 2007 13:43:52 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jan 2007 05:43:52 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of Christian.Poitras@ircm.qc.ca designates 207.162.51.27 as permitted sender) Received: from [207.162.51.27] (HELO pandore.ircm.qc.ca) (207.162.51.27) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jan 2007 05:43:43 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730CF.77713D1A" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Caching by pre-loading Date: Fri, 5 Jan 2007 08:43:22 -0500 Message-ID: <5820E7E2A928DB46824297946AC2024A9A60ED@pandore.ircm.priv> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Caching by pre-loading Thread-Index: AccwYQ6WEe0aKk1NS3O6mRUKOptrLgAbel2Q From: "Poitras Christian" To: X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C730CF.77713D1A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 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. =20 If you must preload your employees, maybe running many "select * from employee where id=3D#id#" at startup with most used ids will give you better results. =20 Christian ________________________________ From: James Johnson [mailto:johnson.james2@gmail.com]=20 Sent: Thursday, 04 January 2007 19:32 To: user-java@ibatis.apache.org Subject: Re: Caching by pre-loading Thanks for the quick response.=20 "iBATIS caches by SQL statement". I thought that was the case. Thanks for confirming.=20 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.=20 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=3D#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=3D#id#"? Perhaps, it's a situation where the best of both worlds is not possible.=20 On 1/4/07, Jeff Butler wrote:=20 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.=20 =20 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?=20 =09 =20 Jeff Butler =09 =20 =20 =20 On 1/4/07, James Johnson wrote:=20 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=3D1", the second query appears to hit the database instead of finding the employee object in the cache with id=3D1. 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.=20 =20 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.=20 =20 Thanks in advance. ------_=_NextPart_001_01C730CF.77713D1A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Maybe you can just use LRU caching. If requests = are often=20 alike, you won't even need to question yourself as long as the cache = size is=20 large enough.
 
If you must preload your employees, = maybe running=20 many "select * from=20 employee where id=3D#id#" at startup with most used ids will give you = better=20 results.
 
Christian

From: James Johnson=20 [mailto:johnson.james2@gmail.com]
Sent: Thursday, 04 January = 2007=20 19:32
To: user-java@ibatis.apache.org
Subject: Re: = Caching=20 by pre-loading

Thanks for the quick response.

"iBATIS caches by SQL=20 statement". I thought that was the case. Thanks for confirming. =

I'm=20 trying to just use iBatis caching. One way that I saw of accomplishing=20 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=20 "select * from employee". iBatis returns the cached results (I'm using a = queryForMap("getAllEmployee", null, "id")). Then I get the employees of = interest=20 by using a get on the Map.

However, except for the first user = request of=20 a given employee, metrics seem to show this to be slower than just = querying=20 "select * from employee where id=3D#id#" for each employee.  Any = ideas on how=20 to use iBatis caching only and have the first response to an user being = cached=20 data (pre-loading) while having subsequent responses be at the speed of = a cached=20 "select * from employee where id=3D#id#"? Perhaps, it's a situation = where the best=20 of both worlds is not possible.



On 1/4/07, Jeff=20 Butler <jeffgbutler@gmail.com> = wrote:
iBATIS caches by SQL statement - your two statements are = different, so=20 there is a cache miss.  This also demonstrates a fundamental = truth about=20 iBATIS - iBATIS doesn't know about object identity.  So iBATIS = would have=20 no way of looking through the first set of cached results to see if an = object=20 from the second statement already is available.
 
You could accomplish what you want by loading all the employees = into some=20 cache that you manage - and then selecting individual employees from = your=20 cache.  Maybe your cache could just be a simple HashMap keyed by = employee=20 id?
 
Jeff Butler
 
 


 
On 1/4/07, James=20 Johnson <johnson.james2@gmail.com=20 > wrote:=20
How does iBatis determine whether = results are=20 to be pulled from the cache or to be queried from the database? = For instance, if I have a query like such: = "select * from=20 employee" and then follow-up with a second query of "select * from = employee=20 where id=3D1", the second query appears to hit the database instead = of finding=20 the employee object in the cache with id=3D1. Is there way to have = iBatis get=20 the object from the cached results of the 1st query? Both queries = are in the=20 same sqlMap xml have the same result map.
 
I'm trying to pre-load all = employees at web=20 application start so that the first user request (for a given set of = employees) doesn't take a = hit on=20 response time. Most user requests are = for 1-10 employees.=20
 
Thanks in=20 = advance.


------_=_NextPart_001_01C730CF.77713D1A--