[
https://issues.apache.org/jira/browse/CASSANDRA-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13765765#comment-13765765
]
Oleg Kibirev commented on CASSANDRA-5988:
-----------------------------------------
Referencing the above JIRA, there is no harm in having smaller hint TTL.
As for optimistic locking, the only other form (CAS) is not available until
cassandra 2.0 and even then does not provide performance for very high volume
operations.
If the objective is to do a user facing operation and a background operation
simultaneously and without external locking, and to have background operation
lose if there is an intervening user operation, backdating the background
operation by a certain amount is a good compromise between consistency and
performance. This feature will safeguard against user operation failing, being
only stored as a hint and then confusing the background process as to ultimate
success or failure of the backdated operation.
> Make hint TTL customizable
> --------------------------
>
> Key: CASSANDRA-5988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5988
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Oleg Kibirev
>
> Currently time to live for stored hints is hardcoded to be gc_grace_seconds.
> This causes problems for applications using backdated deletes as a form of
> optimistic locking. Hints for updates made to the same data on which delete
> was attempted can persist for days, making it impossible to determine if
> delete succeeded by doing read(ALL) after a reasonable delay. We need a way
> to explicitly configure hint TTL, either through schema parameter or through
> a yaml file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
