ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick <ric...@gmail.com>
Subject Couple quick caching clarification questions
Date Wed, 19 Nov 2008 15:15:50 GMT
I have just a few cache clarifications for you guys...

My requirements are actually fairly simple in one regard: Assume the
application is 99% read only data being returned. 95% of that data can
in theory be cached - it's almost all meta-data used to drive display
prompts on a front end. Much of this meta data that comes back from
the db at some point first gets converted to xml in the midtier.

With those requirements in mind here are my questions:

1) Is there an easy hook into the iBATIS to 'flush all of the cache."
Occasionally some db meta data will be modified from outside the
application ( dba sql inserts/updates directly at the tables) at which
point there might be times that I'd like to flush all of the cache
without bringing down the application. I was thinking of somehow using
a JMX component that I can use to directly call the iBATIS api that
would do a mass dump of ALL the cache (I don't really care about it
being that fine grained that I only want to dump individual cache

2) How sufficient is iBATIS' caching for this "read only global data."
 I can care less about per-session cache. Basically if someone does
"Select * from Foo f where f.userID = #userID#" I want that result
cached by:  'the query' and param(s) passed in - which I believe is
how iBATIS' current caching mechanism works.

3) What do recommended for the manual caching that I'll need to use
for caching my XML based on params (which will probably be the same
params iBATIS uses - the query name, and params passed in). I want
SIMPLE. I don't need clustering support, nor do I care about
serializing the data to disk.  Probably I'll use LRU as the caching
for both iBATIS and this manual cache. I heard EHCache is very good so
I'll probably research that.

4) I've heard it mentioned that "iBATIS caching will never be as good
as a true ORM." I'm curious in what regard though? I can see this
being the case for when you care about 'dirty cache (was a cache
instance modified)' but is this "ORM cache being better" hold true for
"READ ONLY" cache as well? I actually did some research a bit last
night and the caching in Hibernate (EHCache) seems a bit odd - the way
it flattens everything out. This article was quite interesting and
some of the issues with it "Hibernate Query Cache: A dirty little
secret" http://darren.oldag.net/2008/11/hibernate-query-cache-dirty-little_04.html
 I'm thinking for read-only data iBATIS' LRU caching should be perfect
for my requirements? In other words, would I gain that much even
trying to plug in a different caching mechanism if all I care about is
read only data ?

Thanks a lot.

View raw message