My vote, if I have one, is for performance optimization on the 1 to many,
many to many queries.
"Thomas Yip"
<yip@intalio. To: [EMAIL PROTECTED]
com> cc:
Subject: Re: [castor-dev] Strategy
Proposal (repost - was: Castor JDO
05/01/2002 Status)
02:09 PM
Please
respond to
castor-dev
>If we're only looking at removing objects
>from the cache, then you are correct.
First, I don't see value of having distributed
cache right now. That's so much more things
to optimize. That will give much more noticeable
different. If you are talking about very long term,
then I really not interested to discuss it right now.
>But I can see the benefits of
>having a cache that may exist external to the JVM that is housing
>castor itself. Think of there being a level1 and level2 cache in
>castor. If we can provide a shared level2 cache system, we can do
>some interesting things where I work explictly in configuration of the
>animal. I'm currently trying to build a level2 cache now, that is not
>only fully distributable, but also sharedable. Having a 'plug' cache
>system helps me here.
You either implementing the second level cache
Transparence to the LockEngine. The LockEngine
load everything through the secondary cache, instead
of the database directly. The secondary cache that
notified LockEngine which cache should be purged.
For LockEngine prescriptive, it is cache purging policy.
If you want to able to have more interactions between
first and secondary cache, (but I doubt if it can be efficient,
because remote cache is magnitudes slowers, that why
we need LockEngine to avoid database calls in the first
place), then I don't see how such interaction be pluggable.
It seems to me you should have your own implementation
of LockEngine. I am pretty sure it is much easier than
design a pluggable architecture.
Thomas
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
