[
https://issues.apache.org/jira/browse/STORM-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15327283#comment-15327283
]
ASF GitHub Bot commented on STORM-1886:
---------------------------------------
Github user arunmahadevan commented on a diff in the pull request:
https://github.com/apache/storm/pull/1470#discussion_r66784961
--- Diff:
external/storm-redis/src/main/java/org/apache/storm/redis/state/RedisKeyValueState.java
---
@@ -77,7 +81,8 @@ public RedisKeyValueState(String namespace,
JedisCommandsInstanceContainer jedis
this.keySerializer = keySerializer;
this.valueSerializer = valueSerializer;
this.jedisContainer = jedisContainer;
- this.pendingPrepare = new ConcurrentHashMap<>();
--- End diff --
Could we somehow handle the deletes by maintaining an entry (with some
extra info) within the pendingPrepare itself and avoid the extra hash sets and
synchronized ? Something along the lines of maintaining a map of
`key -> {ADD or DELETE, value}`. The values to be deleted could be written
to a separate Redis Set during prepare.
During `delete`, insert a DELETE entry into pendingPrepare.
During `prepare`, snapshot pendingPrepare to pendingCommit and also save
the DELETE entries to a redis set.
During `commit`, delete the DELETE entries from redis map.
During `get`, if key is in pendingPrepare, pendingCommit with DELETE or the
key is not found return null.
> Extend KeyValueState interface with delete method
> -------------------------------------------------
>
> Key: STORM-1886
> URL: https://issues.apache.org/jira/browse/STORM-1886
> Project: Apache Storm
> Issue Type: Improvement
> Reporter: Balazs Kossovics
>
> Even if the implementation of checkpointing only uses the get/put methods of
> the KeyValueState interface, the existance of a delete method could be really
> useful in the general case.
> I made a first implementation, what do you think about?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
