Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 13 Nov 2017 19:43:00 +0000 (UTC)
From: "Alex Petrov (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13116066.1509744920000.224253.1510602180637@Atlassian.JIRA>
In-Reply-To: <JIRA.13116066.1509744920000@Atlassian.JIRA>
References: <JIRA.13116066.1509744920000@Atlassian.JIRA> <JIRA.13116066.1509744920537@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13992) Don't send new_metadata_id for
 conditional updates
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 13 Nov 2017 19:43:06 -0000


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

Alex Petrov commented on CASSANDRA-13992:
-----------------------------------------

[~omichallat] not sure, since {{METADATA_CHANGED}} is just a flag: e.g. if it's set it's {{true}}, otherwise it's {{false}}. Moreover, I think that the default behaviour for LWTs has to be that we _always_ update metadata: there's no way for server to know what was the last metadata on the client (since it depends on the result), the server can't distinguish between the metadata hash inequality caused by {{ALTER}} vs caused by success/non-success LWT result.

Unless I'm missing something, my patch achieves exactly that (also, without any driver changes): it forces the server to _always_ send the metadata. This, combined with the metadata consisting of zeroes can instruct the client that caching metadata is possible, but won't bring anything: new result metadata will just be re-delivered on every call, since it's potentially going to be changing on every request.

> Don't send new_metadata_id for conditional updates
> --------------------------------------------------
>
>                 Key: CASSANDRA-13992
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13992
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Olivier Michallat
>            Assignee: Kurt Greaves
>            Priority: Minor
>
> This is a follow-up to CASSANDRA-10786.
> Given the table
> {code}
> CREATE TABLE foo (k int PRIMARY KEY)
> {code}
> And the prepared statement
> {code}
> INSERT INTO foo (k) VALUES (?) IF NOT EXISTS
> {code}
> The result set metadata changes depending on the outcome of the update:
> * if the row didn't exist, there is only a single column \[applied] = true
> * if it did, the result contains \[applied] = false, plus the current value of column k.
> The way this was handled so far is that the PREPARED response contains no result set metadata, and therefore all EXECUTE messages have SKIP_METADATA = false, and the responses always include the full (and correct) metadata.
> CASSANDRA-10786 still sends the PREPARED response with no metadata, *but the response to EXECUTE now contains a {{new_metadata_id}}*. The driver thinks it is because of a schema change, and updates its local copy of the prepared statement's result metadata.
> The next EXECUTE is sent with SKIP_METADATA = true, but the server appears to ignore that, and still sends the metadata in the response. So each response includes the correct metadata, the driver uses it, and there is no visible issue for client code.
> The only drawback is that the driver updates its local copy of the metadata unnecessarily, every time. We can work around that by only updating if we had metadata before, at the cost of an extra volatile read. But I think the best thing to do would be to never send a {{new_metadata_id}} in for a conditional update.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org