[
https://issues.apache.org/jira/browse/SAMZA-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14164013#comment-14164013
]
Chris Riccomini commented on SAMZA-424:
---------------------------------------
Thinking on the isShared method a bit more. It would be nice if we could avoid
this method. It introduces the weirdness that I described above, and feels kind
of hacky. Maybe there's a way to not have this, and to just have shared stores
only registered once per-container?
Also, we might want to take this opportunity to change the
StorageEngine.restore() method to StorageEngine.putAll() (or something like
this). We'll need put's for SAMZA-402, since there will be incremental updates
as continuous updates flow in for global stores.
> 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_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)
