[
https://issues.apache.org/jira/browse/SAMZA-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165557#comment-14165557
]
Jay Kreps commented on SAMZA-424:
---------------------------------
Yeah with respect to logging it is still a bit dubious, right? It will be
pretty hard to reason about whether the cost of the logging will outweigh the
benefit of the cache. It may definitely help to keep the warm cache around but
that may or may not sufficiently protect the db...kind of depends on the
cachability I suppose. If you want to limit calls, probably better to do that
directly by throttling right?
I agree that having a mechanism to share objects would be very useful but this
isn't specific to caching right? Basically any kind of singleton you want to
inject in all tasks would want this. I see this more as a generalization of
init() but for the container not the task with a mechanism to somehow stash
objects somewhere where you could retrieve them in the task or in the task
init. The equivalent of the ServletContext in servlet programming.
> 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)
