cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
Date Tue, 18 Jun 2013 17:12:21 GMT


Sylvain Lebresne updated CASSANDRA-5619:

    Attachment: 5619.txt

Attaching patch for this that implement the idea above.

I do note that while coding this I realized that 'IF NOT EXIST' wasn't always working correctly
in CQL3, because in the underlying SP.cas() method we were fetching the first column of the
partition (internal row), but such column might not at all be part of the CQL3 row we are
interested in. The patch provides a fix for this (we could create a specific ticket for the
bug, but if we're fine on that ticket, not sure it's worth bothering).

Talking of 'IF NOT EXISTS', there was the question of what to return. For CQL3, I've made
it so that we return the full CQL3 row as it felt like it was making the more sense. For thrift
however, since we don't want to return the full partition, it only returns the first live
column of the partition.

Note: the patch includes the change to the generated thrift files.
> CAS UPDATE for a lost race: save round trip by returning column values
> ----------------------------------------------------------------------
>                 Key: CASSANDRA-5619
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.0
>            Reporter: Blair Zajac
>            Assignee: Sylvain Lebresne
>             Fix For: 2.0
>         Attachments: 5619.txt
> Looking at the new CAS CQL3 support examples [1], if one lost a race for an UPDATE, to
save a round trip to get the current values to decide if you need to perform your work, could
the columns that were used in the IF clause also be returned to the caller?  Maybe the columns
values as part of the SET part could also be returned.
> I don't know if this is generally useful though.
> In the case of creating a new user account with a given username which is the partition
key, if one lost the race to another person creating an account with the same username, it
doesn't matter to the loser what the column values are, just that they lost.
> I'm new to Cassandra, so maybe there's other use cases, such as doing incremental amount
of work on a row.  In pure Java projects I've done while loops around AtomicReference.html#compareAndSet()
until the work was done on the referenced object to handle multiple threads each making forward
progress in updating the references object.
> [1]

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