cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9200) Sequences
Date Wed, 13 May 2015 15:09:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14542070#comment-14542070
] 

Robert Stupp commented on CASSANDRA-9200:
-----------------------------------------

It's due to the loop
{code}
     "SELECT next_val, exhausted FROM system_distributed.seq_reservations WHERE ..."     
 <-- done with "CONSISTENCY LEVEL"
     nextVal = boundedAddAndExhaustedCheck ( nextVal, exhausted )
     "UPDATE system_distributed.seq_reservations SET ... IF next_val =?"    <-- done with
"SERIAL CONSISTENCY LEVEL"
{code}

The other writes are the initial INSERT (w/SERIAL) and final DELETE.

> Sequences
> ---------
>
>                 Key: CASSANDRA-9200
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9200
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Jonathan Ellis
>            Assignee: Robert Stupp
>             Fix For: 3.x
>
>
> UUIDs are usually the right choice for surrogate keys, but sometimes application constraints
dictate an increasing numeric value.
> We could do this by using LWT to reserve "blocks" of the sequence for each member of
the cluster, which would eliminate paxos contention at the cost of not being strictly increasing.
> PostgreSQL syntax: http://www.postgresql.org/docs/9.4/static/sql-createsequence.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message