[jira] [Updated] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-5619: Labels: LWT (was: ) > CAS UPDATE for a lost race: save round trip by returning column values > -- > > Key: CASSANDRA-5619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 > Project: Cassandra > Issue Type: Improvement >Affects Versions: 2.0 beta 1 >Reporter: Blair Zajac >Assignee: Sylvain Lebresne >Priority: Major > Labels: LWT > Fix For: 2.0 beta 1 > > Attachments: 0001-Add-back-boolean-result-column.txt, 5619.txt, > 5619_thrift_fixup.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] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5619: Attachment: 0001-Add-back-boolean-result-column.txt Adding patch for adding the success boolean because I don't have a better idea right now. CAS UPDATE for a lost race: save round trip by returning column values -- Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 beta 1 Reporter: Blair Zajac Assignee: Sylvain Lebresne Fix For: 2.0 beta 1 Attachments: 0001-Add-back-boolean-result-column.txt, 5619_thrift_fixup.txt, 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] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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
[jira] [Updated] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5619: Attachment: (was: 5619_thrift_fixup.txt) CAS UPDATE for a lost race: save round trip by returning column values -- Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 beta 1 Reporter: Blair Zajac Assignee: Sylvain Lebresne Fix For: 2.0 beta 1 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] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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
[jira] [Updated] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
[
https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5619:
Attachment: 5619_thrift_fixup.txt
bq. How do we differentiate now between it didn't work, because the row
doesn't exist and you specified non-empty columns and it did work?
Right, that doesn't work. Well, the only solution I see is to create a special:
{noformat}
struct CASResult {
1: required bool success,
2: optional listColumn current_values,
}
{noformat}
and to return that from the CAS in thrift. I updated the patch to do that (and
updated the test_cas accordingly).
bq. -0 on allowing both null and empty in parameters
Fair enough. But I'm -1 on allowing null but not empty because that would be
extra weird API wise, so changed the patch to only allow empty. I guess this is
consistent with the rest of the Thrift API were we don't allow null anywhere.
bq. How do we differentiate now between it didn't work, because the row
doesn't exist and you specified non-empty columns and it did work?
Right, that doesn't work. Well, the only solution I see is to create a special:
{noformat}
struct CASResult {
1: required bool success,
2: optional listColumn current_values,
}
{noformat}
and to return that from the CAS in thrift. I updated the patch to do that (and
updated the test_cas accordingly).
bq. -0 on allowing both null and empty in parameters
Fair enough. But I'm -1 on allowing null but not empty because that would be
extra weird API wise, so changed the patch to only allow empty. I guess this is
consistent with the rest of the Thrift API were we don't allow null anywhere.
CAS UPDATE for a lost race: save round trip by returning column values
--
Key: CASSANDRA-5619
URL: https://issues.apache.org/jira/browse/CASSANDRA-5619
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 2.0 beta 1
Reporter: Blair Zajac
Assignee: Sylvain Lebresne
Fix For: 2.0 beta 1
Attachments: 5619_thrift_fixup.txt, 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] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044
--
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
[jira] [Updated] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5619: Attachment: 5619_thrift_fixup.txt Damn you thrift. I guess returning an empty list works as well so attaching a simple patch to do that. I changed it only on the thrift side, and not in the StorageProxy call cause it felt cleaner internally to keep null, and I didn't saw the point of allocating an empty CF object in the CQL3 case. The patch also make is so that expected.isEmpty() tests existence (like expected == null). It's what makes sense and I figured that maybe Thrift can't pass null as parameter either so ... CAS UPDATE for a lost race: save round trip by returning column values -- Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 beta 1 Reporter: Blair Zajac Assignee: Sylvain Lebresne Fix For: 2.0 beta 1 Attachments: 5619_thrift_fixup.txt, 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] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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
[jira] [Updated] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5619: Fix Version/s: 2.0 CAS UPDATE for a lost race: save round trip by returning column values -- Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 Reporter: Blair Zajac Assignee: Sylvain Lebresne Fix For: 2.0 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] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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
[jira] [Updated] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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: https://issues.apache.org/jira/browse/CASSANDRA-5619 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] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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
