[
https://issues.apache.org/jira/browse/SAMZA-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14164043#comment-14164043
]
Chris Riccomini commented on SAMZA-424:
---------------------------------------
I'm wondering if we're conflating multiple things here. It feels a bit like
we're trying to solve Samza's config/wiring issues (SAMZA-40) here, in a
localized manner, just for state management. The more I dig into the edge cases
for context.registerStorageEngine, the more it feels like we just need to take
a step back and try to solve the config issue holistically, rather than just
try to make it better for state.
My concern here is that changing the TaskContext API might not be needed when
we refactor Samza's configuration API. In that case, we're stuck with a
backwards incompatible change (.getStore -> .registerStorageEngine), and then
probably a change back to .getStore.
This seems to me to be a compelling reason to simply do composition via
configuration, and then tackle SAMZA-40 holistically, and be mindful that we
solve the store composition issue in that ticket.
> 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)
