Ok... My mail I sent yesterday didn't get through... here it is again...
Thomas-
I can agree that simple replacement of the LRU isn't all that is
needed... and that 'removal' of objects is more of a suggestion to the
LRU than a demand due to locking. Furthermore, I do also agree that
the policy for removal is the initial concern for Castor,a dn that the
policy needs to be inside the LockEngine itself. (Course, the policy
should be 'plugable', in my view)
This is obviously a complex issue. My point is that we need to make
these items plugable since needs may change. The policy needs to be
implemented, but since we're starting it from scratch, we might as
well make it a configuration param in the properties file too. Do you
agree with this?
The issue with the cache itself being plugable may seem silly, since
the cache isn't shared. If we're only looking at removing objects
from the cache, then you are correct. 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.
If this still doesn't sound like a good direction to go, then I'll
drop it (for now) and would start working on a plugable policy
technique for removing the cache items instead.
> From: "Thomas Yip" <[EMAIL PROTECTED]>
> Date: Tue, 30 Apr 2002 11:18:46 -0700
>
> Hi Ned,
>
>
> The LRU implementation itself is only a Hashtable replacement
> that expires the least recently used objects.
>
> However, simply clearing what is in the LRU is certainly not
> enough to implement cache eviction, not to mention distributed
> cache. Because object that should be evicted might be kept in
> locks. However, those locks can't be evicted forcefully. Because,
> transaction using it depends on it. And, it needs the values of
> the locked object in all phrases of transaction, and it should
> not be removed or have its values change at all. LockEngine
> is designed just for that.
>
> So, the problem is not to replace LRU cache, but implements
> cache purging policy inside LockEngine. The policy must aware
> of transaction, and doesn't influence them. At the same time, it
> must make sure in the end of those transaction all locks and
> cache of the evicting object are actually cleared.
> The next step is to make cache-purging policy pluggable.
>
> LRU cache and distributed cache sounds similar, but they
> don't interchange each other.
--
Virtually,
Ned Wolpert <[EMAIL PROTECTED]>
D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
