ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From reub...@sonic.net
Subject Re: Cache w/ Hierarchical ResultMaps
Date Wed, 02 Nov 2005 17:30:29 GMT
Hi Clinton, this is actually use case based.

Let me put *example* names to my tables to illustrate:

Vendor / Branch / Employee / Address

When I load a Vendor, I wish (if at all possible) to load it from the
cache, since it contains all sub objects (Branch, Employee, Address), and
is rather big.

However, when an Employee of a Vendor has a change of Address, I don't
want to have to save the whole Vendor, or even the whole Branch.
Therefore, in the cache model for Vendor, I have to include a line to
flush the cache whenever an Employee record is updated.

This way of doing things seems to have high potential for introduction of
bugs: Let's say that another member of my development team is responsible
for adding a new mutator at the Employee level of things. It's going to
take a lot of hair pulling on their part before they discover the caching
of Employees taking place at the Vendor level. Perhaps their junit tests
might even succeed if they mutate the Employee/Address *before* pulling
the Vendor (and thus populating the cache.)

In my proposed model, there would be a cache at the Employee or Address
level (i.e. in the sqlMap for one of those sub objects.) The Vendor cache
would delegate to this cache for Employee/Address objects; therefore,
flushing on Employee mutators could take place within the same namespace.
This seems infinitely cleaner to me.

(Incidentally, I opened a JIRA ticket on this last week, after receiving
no response on the list... feel free to close that if I still haven't
convinced you  :) .)

Thanks


> I would suggest to avoid building cache models of that complexity.
> Remember,
> cache models are not intended to be associated with result maps, nor
> dependencies based on result map configurations.
>
> iBATIS cache models are statement (a.k.a. use case) based, not object id (
> a.k.a. holistic) caches.
>
> You should be designing your caches around usage scenarios, not around the
> object model.
>
> Cheers,
> Clinton
>
>
> On 10/26/05, reubenf@sonic.net <reubenf@sonic.net> wrote:
>>
>> Hello, I found that the cache doesn't behave exactly as I'd have
>> expected;
>> I'm using an LRU cache. Is there a way that I can configure it to behave
>> as I'd like?
>>
>> I have a hierarchical object tree, mapped using ResultMaps:
>>
>> <select id="getA" ... resultMap="Map_A" cacheModel="Cache_A"> ...
>>
>> <resultMap id="Map_A">
>> <result property="B" column="a_id" select="B.getB">
>> ...
>>
>> I am caching A. It looks like all of the Bs that belong to A are also
>> cached as part of this, such that if I change a property of B directly
>> (without saving A -- the "saveA" operation causes the cache to flush) I
>> cannot access this new B information by calling "getA" again (since the
>> old B is stored in the cache).
>>
>> I can get around this by adding all of the mutateB..Z statements to A's
>> cachemodel, but this is inelegant, since I'm now mixing namespaces, and
>> could lead to bugs creeping into the project, since developers may not
>> realize that there is a cache at A when they are adding the mutateN
>> statement. I would like instead for B..Z to have their own cachemodel,
>> and
>> for A to get its Bs from B's cachemodel instead of from within its own.
>> That way, A's cachemodel can worry only about A mutators; B's can worry
>> about B mutators, etc etc.
>>
>> Does this make sense, and is it possible to do this using current
>> syntax?
>>
>> Thanks
>> Reuben
>>
>>
>>
>>
>



Mime
View raw message