To answer your questions:
>> Does flush really mean flush?
Yep. There's no invalidate or "dirty state". It's either there, or it's not.
>> When you have a flush-on-insert setup
>> does the caches truly flush all elements in the cache?
Yep.
>> If so what is the reason behind doing that?
The reason is primarily technical. The simple answer is: there's no other way to do it.
The complex reason is that iBATIS doesn't support the idea of object identity (OI). We can't invalidate, remove or update individual objects based on their identity, because we don't know what that identity is. Because iBATIS isn't an ORM, we've never been too concerned with OI, and the biggest tradeoff for that is the cache model. iBATIS performs query caching. Basically, the combination of the SQL statement and the parameters you set upon it make up the key. The results are what is cached. A list counts as one cache entry. The following 3 statements would result in different keys:
SELECT * FROM PERSON WHERE PERSON_ID = 3;
SELECT * FROM PERSON WHERE PERSON_ID = 9; -- different parameter
SELECT * FROM DEPARTMENT WHERE DEPARTMENT = 5; -- different statement
You can achieve fairly smart caching by separating your list caches from your single instance caches, and by separating the caches by type (i.e. class). Obviously this takes some extra effort and a lot of tweaking of the cache model.
That said....
In performance testing that I've been involved in in various contexts, I've found that no generic cache can ever beat a context specific cache. That is, whether your dealing with a strict query cache like iBATIS, or even a very powerful OI based cache like in Hibernate, I will always be able to beat it by writing a context specific cache. A context specific cache is one that you develop exclusively to meet the needs of your particular domain and user interaction scenarios. Of course, in doing so you can use 3rd party cache products like OSCache or EHCache.
Hope that helps.
Cheers,
Clinton
On 5/15/05, Nathan Maves <[EMAIL PROTECTED]> wrote:
I have not looked into the source code yet but I want to get some of the
basics questions out there first.
The real question is ...
Does flush really mean flush? When you have a flush-on-insert setup
does the caches truly flush all elements in the cache? If so what is
the reason behind doing that? This question really applies to all of
the flush commands.
I assume that the caches use some sort of java.util.Map to store the
cached objects. What are they keyed on?
Nathan
