[
https://issues.apache.org/jira/browse/SAMZA-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155691#comment-14155691
]
Chris Riccomini commented on SAMZA-424:
---------------------------------------
[~sriramsub], I think your summary is pretty much correct. A few comments:
bq. Also, what does caching mean here? It looks like we just want to provide an
eviction policy to the store and we should avoid calling it as an explicit
cache mode.
Agreed. I think we'd just be augmenting our existing CacheStore, and adding an
eviction policy, as you described.
bq. This is not possible in option 1 since they would have to explicitly put
messages into the store after reading it from a remote store.
I'm not so sure. In option 1, if we implement a VoldemortStore, and use that as
the underlying storage engine, then the CacheStore would automatically cache
things in its LRU cache. In essence, the current CacheStore that we have
already acts as a read-through and write-behind cache.
I think I'm currently leaning towards option (1).
> 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
>
>
> 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)
