[
https://issues.apache.org/jira/browse/SAMZA-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14164097#comment-14164097
]
Sriram Subramanian commented on SAMZA-424:
------------------------------------------
The composition seems to be in line with our discussion. However, I am not sure
if this is the right JIRA to discuss about shared and global states. It seems
like it would be simpler to just focus on composing local states for this task.
W.r.t how we compose states, I agree with Chris. The config vs code is an
important discussion outside the state discussion. We would have to come up
with a way to differentiate clearly what needs to be through config and what
needs to be done via code. Also, my vote would be to keep this change less
intrusive by supporting ways to compose local states using configs and later
change it after we have a consensus on the config vs code approach. I think
they can be decoupled and we could also do a backwards compatible way of
migrating from config to code.
> 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)
