[
https://issues.apache.org/jira/browse/SAMZA-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165343#comment-14165343
]
Yan Fang commented on SAMZA-424:
--------------------------------
If my understanding is correct, the cache layer is trying to give LRU and TTL
eviction strategies, then I am leaning to the option (1) in Sriram's comment as
well because it avoids introducing a new API and is backwards compatible.
The proposal looks good, a few questions:
1) where does the user input values to the cache layer in a real use case?
2) can the cache layer share the same keyValueStore as the store? e.g. the
cache and the store both are using the same RocksDB.
3)
{quote}
Implement the different backing stores required (eg: VoldemortBackingStore).
{quote}
Does the backingStore need a new API? Otherwise, like Martin comments "_I can't
quite see how you could wrap, say, a Lucene storage engine with a
key-value-oriented cache._"
> Add a Cache state API to the Samza container
> --------------------------------------------
>
> Key: SAMZA-424
> URL: https://issues.apache.org/jira/browse/SAMZA-424
> Project: Samza
> Issue Type: New Feature
> Components: container
> Reporter: Chinmay Soman
> Assignee: Chinmay Soman
> Attachments: SAMZA-424-Cache-API_0.pdf, SAMZA-424-Cache-API_1.md,
> SAMZA-424-Cache-API_2.md, SAMZA-424-Cache-API_2.pdf, samza-424-cache-api_1.pdf
>
>
> There are cases when the user code needs access to a 'cache' which can be
> used to store custom data. This cache is different from the KeyValue store in
> the following ways:
> * At the very least Needs to support LRU (Least Recently Used) and TTL (Time
> To Live) eviction strategies
> * May not support all() and range() operations (since this wreaks havoc with
> the eviction operation)
> * Needs to exist at a per task or a per container level.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
