[
https://issues.apache.org/jira/browse/ZOOKEEPER-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906503#action_12906503
]
Thomas Koch commented on ZOOKEEPER-866:
---------------------------------------
Thinking more about this, I'd consider this requirement a premature
optimization. Wouldn't it be much more important to make ZK rock solid stable,
well documented (also the code) and polish the usability of ZK before worrying
about speed?
Are you sure, that there's no other way to solve the issue at hand? Instead of
fine grained locking, maybe it'd be possible to lock packages at once. Or some
kind of constant hashing: By placing a node on a constant hashing ring, I lock
everything until the next node.
It'd be interesting to see the use case that require such fine grained locking,
if that'd be possible.
> Adding no disk persistence option in zookeeper.
> -----------------------------------------------
>
> Key: ZOOKEEPER-866
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-866
> Project: Zookeeper
> Issue Type: New Feature
> Reporter: Mahadev konar
> Assignee: Mahadev konar
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-nodisk.patch
>
>
> Its been seen that some folks would like to use zookeeper for very fine
> grained locking. Also, in there use case they are fine with loosing all old
> zookeeper state if they reboot zookeeper or zookeeper goes down. The use case
> is more of a runtime locking wherein forgetting the state of locks is
> acceptable in case of a zookeeper reboot. Not logging to disk allows high
> throughput on and low latency on the writes to zookeeper. This would be a
> configuration option to set (ofcourse the default would be logging to disk).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
