cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kibirev (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5988) Make hint TTL customizable
Date Thu, 12 Sep 2013 18:45:55 GMT


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:
>             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:

View raw message