[
https://issues.apache.org/jira/browse/SAMZA-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165537#comment-14165537
]
Chinmay Soman commented on SAMZA-424:
-------------------------------------
bq. Why can't the user just instantiate ehcache or the cache of their choice
and use it? This seems like a simpler and better user experience than our
trying to wrap all caches in some way.
[~jkreps] : I can think of 2 use cases where framework support might be better:
* We might actually want changelog for the cached items (so that we support
warm caches). This is useful since this avoids pounding the remote DB every
time we restart.
* In case of read-only caches (which can be used via the ReadOnlyKeyValueStore
interface), it might be useful to share the cache between the different tasks
in the same container. Of course - the user code can simply do this by use of
static (and with some flags) - but that seems a bit hacky.
There might be other good reasons. Although you're right - I don't have a
pressing reason why we should do this.
> 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)
