I see the source.
1. ( null == map.get( key ) ) != ( map.containsKey( key ) )
do not use null == map.get( key ) for cache item existence check.
DefaultCache.containsKey is misimplemented.
I will write more documentation. sorry.
2. Why use ( size() > m_capacity )?
It is commented "cache full?"
isFull() is defined in AbstractCache like below
public boolean isFull()
{
return size() >= capacity();
}
remove "cache full" comment if " (size() > m_capacity) "
3. How about FlipSpacesStore for its name?
----- Original Message -----
From: "MCCAY,LARRY (HP-NewJersey,ex2)" <[EMAIL PROTECTED]>
To: "'Avalon Developers List'" <[EMAIL PROTECTED]>
Sent: Tuesday, January 08, 2002 2:35 AM
Subject: RE: excalibur.cache.LRUCachePolicy
> Eung-Ju,
>
> Attached is an implementation of a CacheStore that you may find
interesting.
>
>
> It does not, however, require a CachePolicy.
>
> It is based on the 2 Data Spaces pattern for LRU caching.
>
> I modified the LRUCacheTestCase just to test it before sending it - I'll
let
> you determine if you actually roll it in.
>
> enjoy.
>
> Larry
>
> > -----Original Message-----
> > From: Eung-ju Park [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 07, 2002 2:03 AM
> > To: Avalon Developers List
> > Subject: Re: excalibur.cache.LRUCachePolicy
> >
> >
> > Hi.
> >
> > ----- Original Message -----
> > From: "Alexis Agahi" <[EMAIL PROTECTED]>
> > To: "'Avalon Developers List'" <[EMAIL PROTECTED]>
> > Sent: Monday, January 07, 2002 8:17 AM
> > Subject: excalibur.cache.LRUCachePolicy
> >
> >
> > > Hi,
> > >
> > > I've checked the cache implementation from excalibur scratchpad
> > > and notice that LRUCachePolicy use the ListCachePolicy LinkedList
> > > to perform the LRU mecanism.
> > >
> > > To have a LRU 'hit' effect, it removes the object from the list
> > > and put it at the top.
> > > What if the list is really huge? I mean, to perform the remove it
> >
> > It is not a Cache if it is really huge. ;-) Just kidding.
> >
> > > has to scan the whole list, since it doesn't have an index (or
> > > I'm wrong)?
> > >
> > > I would suggest having another approach using a logical clock
> > > value and 'time' hashmap.
> > >
> > > Something like:
> > > When a 'hit' is called, it gets the current object and set its
> > > 'value' to the current logical time.
> > > To remove the oldest, it gets the oldest value in the time map.
> > >
> > > To be really honest, this approach is not necessarily the best:
> > > the remove case is slower that the linked list one, but the 'hit'
> > > could be faster. Now it depends on the hit/remove ratio. But I
> > > guess in an LRU cache, you should have a maximum of 'hit' call.
> >
> > Yes. If you want that kind of ReplacementPolicy. Just
> > implement it. and use
> > like bellow.
> >
> > final Cache cache = new DefaultCache( new TimeMapLRUCachePolicy(),
> > MemoryCacheStore( 1000000000 ) );
> >
> > and test it.
> > and send to this list.
> >
> > Thanks.
> >
> > >
> > >
> > > Regards
> > >
> > > --
> > > mailto:[EMAIL PROTECTED] -
> > > http://sourceforge.net/projects/jabaserver
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
