Hi Toby,

> I started desigining the new features for Cache 1.4, which should
> realize hierarchical caching. Since this topic is not trivial, I
> started with a short summary of requirements and problems to be
> solved.
>
> Please review this and state your comments.

I think, the idea is quite nice. But I guess, implementing this in a 
good and fast way, isn't that easy... Here are some comments/questions:

- Do you want to provide a possibility to choose between the use cache 
storage depending on the cache item type? E.g.: never store the user 
object on file system because it may be faster to reload from database; 
never store images in local RAM because there is not enough place for 
that. (Maybe this could be solved using several caching stacks for 
different ojects.)

- For me, it's not really clear, when you want to replace from top to 
bottom and vice versa. (Maybe the following covers a little bit too 
much replacement strategies in detail that could be application 
specific - but I want to point to the fact that there are perhaps some 
implications in the design document that are contrary.)

> - **Bubbling restored data up through the cache stack**
>   According to the replacement strategy, cache items need to be placed 
>   into higher levels of the hierarchy, as soon as they get restored
>   from a deeper level, to make them available faster on subsequent
>   restore requests. For more information see the `Replacement
>   strategies`_ section.

-> Does this imply that new items are always stored in the slowest cache 
storage in the beginning?

-> Is it really true, that a cached item needs to go to a higher level 
if it is requested? Or should there be some strategy, like Most 
Frequently Used: if a cache item from file system is requested more 
than X times in the last Y seconds, put it in memcached. This may be a 
little bit slower for frequently used items in the beginning (till they 
reached the RAM). But it should reduce the replacements to a minimum.

> Propagate in store
> ^^^^^^^^^^^^^^^^^^

and

> Propagate on replacement
> ^^^^^^^^^^^^^^^^^^^^^^^^

-> Does this imply that new items are always stored in the fastes cache 
storage in the beginning? If yes, there is another big con: on 
applications that permanently produce many new cache items, even items 
that are only used a few times are allowed to replace frequently used 
items from the fastes storage.


Have a nice day

Thomas
-- 
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components

Reply via email to