Daniel Hoppe <[EMAIL PROTECTED]> writes:
> Hi Alex,
>
> >>
> >> - drops the oldest value objects,
> >> - drops the ones with the longest interim since the last hit
> >> - drops the ones with the fewest number of total hits
>
> >This seems interesting. Why should you use one or the other? Would you,
> >e.g., use the first type to save computations? (At first sight, there
> >shouldn't make too much of a difference, but perhaps the way of sorting
> >the objects does.)
>
> Actually I would generally like to have some kind of mixed strategy between
> longest interim and fewest number of total hits which should to some degree
> be configurable. I need this for a content management system where the page
> generation is computation intensive, and I am not too sure yet which caching
> strategy would be the best fit, so if I can configure it I can still play
> around with the settings during load testing. My problem is that my
> implementation for the longest interim is quite inefficient (I keep the keys
> in a LinkedList where they are (re)inserted at the first position on
> access, the times I profiled for this (esp. linkedList.remove()) makes me
> doubt that my approach is smashing so far...). Dropping the oldest value
> object is straightforward and fast as I do never need to reorder the keys.
> Better approaches on this are more than welcome!
Turbine's SequencedHashtable/BufferCache also uses a LinkedList to
keep track of of the order in which key/value pairs are added to the
Map. It's better than nothing, but I also would enjoy hearing about
alternate implementations...
Dan
