Hi Clinton,
(Thanks for commenting - really appreciated.)
Is your suggestion that we'd rather interface with OSCache directly (and separately) instead of relying on the integrated iBatis approach? Can you briefly explain how that would afford us better performance instead? (To be honest, I'd feel more comfortable :) to stick with the existing integrated architecture of iBatis' caching!)
Also, we had prototyped a "hack" in a 1.3.x release of iBatis where we modified iBatis code to mutate the cached object directly (I recall asking whether a public API could be made available ...). That "hack" seemed to work, but the project never really got off the ground and so we couldn't test it in controlled environment. Would that approach not be advisable to take with the latest version of iBatis?
Thanks once again for your assistance,
Kind regards,
Abdullah
Clinton Begin wrote:
I would suggest you don't use the iBATIS cache and instead write your own. It's been proven to me numerous times that an application (i.e. business domain) level cache cannot be beaten in terms of performance. This is especially true considering your complex requirements.
Alternatively, you could try taking one of the open source caches (OSCache, EHCache) or even a commercial one (Tangosol Coherence) and modify it or extend it to your needs.
Cheers, Clinton
