[
https://issues.apache.org/jira/browse/KAFKA-7420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664348#comment-16664348
]
Matthias J. Sax commented on KAFKA-7420:
----------------------------------------
Kafka supports two types of stores that can be added via
`Topology#addStateStore()` and `Topology#addGlobalStateStore()`. Global stores
are maintained by `GlobalStreamThread` and only this thread is allowed to write
into global stores.
However, any `Processor` (that are executed by `StreamThread`) can get access
to all global stores during runtime via `ProcessorContext#getStateStore(...)`
what allow those thread to also write into the store. This is implemented in
`ProcessorContextImpl`. I think, for a fix it would be sufficient to wrap any
"global store" that is returned from `stateManager.getGlobalStore()` with a
ReadOnlyStore – at least for the build-in stores. For custom stores, that
should be rare, we don't have enough information to guard against write access.
Does this help?
> Global stores should be guarded as read-only for regular tasks
> --------------------------------------------------------------
>
> Key: KAFKA-7420
> URL: https://issues.apache.org/jira/browse/KAFKA-7420
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Matthias J. Sax
> Assignee: Nikolay Izhikov
> Priority: Minor
> Labels: newbie++
>
> Global stores should only be update by the global thread. Any other task,
> should only read from a global store. However, when getting a reference to a
> global store, all tasks have full read/write access to the store.
> We should put a guard in place and only return either _(a)_ a read-only
> store, or _(b)_ wrap the store but throw an exception on write for regular
> tasks.
> While the read-only store idea might be cleaner from an API point of view, we
> should consider the second approach for 2 reasons: (1) it's backwards
> compatible (of course, code might fail at runtime, but this seems to be ok,
> as it indicates a bug in the user code anyway) (2) with regard to
> [KIP-358|https://cwiki.apache.org/confluence/display/KAFKA/KIP-358%3A+Migrate+Streams+API+to+Duration+instead+of+long+ms+times],
> we should have the more runtime efficient methods at this level (currently,
> global stores are only key-value stores and this argument falls a little
> short though—however, it might be a good idea to stay future proof; at least,
> we should discuss it).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
