Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 19 May 2016 16:05:13 +0000 (UTC)
From: "Tyler Hobbs (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12916909.1448876954000.237390.1463673913307@Atlassian.JIRA>
In-Reply-To: <JIRA.12916909.1448876954000@Atlassian.JIRA>
References: <JIRA.12916909.1448876954000@Atlassian.JIRA> <JIRA.12916909.1448876954569@arcas>
Subject: [jira] [Issue Comment Deleted] (CASSANDRA-10786) Include hash of
 result set metadata in prepared statement id
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 19 May 2016 16:05:15 -0000


     [ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=3Dcom.atl=
assian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tyler Hobbs updated CASSANDRA-10786:
------------------------------------
    Comment: was deleted

(was: I like the idea of using a separate hash/ID for the statement and the=
 result set metadata if we want to fix the "prepare storm" problem at the s=
ame time.

Overall, it seems like it would work like this:
* In response to a PREPARE message, the server returns a statement ID and a=
 result set metadata ID.
* When performing an EXECUTE, the driver sends both IDs.
* If the prepared statement ID isn't found, the server responds with an "un=
prepared" error, and the driver needs to reprepare as usual.
* If the statement ID is found, but the metadata ID doesn't match, the serv=
er executes the query and responds with a special results message.  This me=
ssage contains the correct result set metadata and its ID, the prepared sta=
tement ID, and a flag to indicate that it's doing this.
* When the driver receives this special response, it replaces its internal =
result set metadata with the new one from the response.

In the scenario Robert describes above (some nodes have seen a schema chang=
e, others haven't), this would avoid repreparation of statements.  The driv=
er might end up swapping its internal result set metadata for the statement=
 several times, but that's relatively inexpensive.)

> Include hash of result set metadata in prepared statement id
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-10786
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1078=
6
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL
>            Reporter: Olivier Michallat
>            Assignee: Alex Petrov
>            Priority: Minor
>              Labels: client-impacting, protocolv5
>             Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a pre=
pared statement when the table is altered, to force clients to update their=
 local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host=
. The first client to execute the query after the cache was invalidated wil=
l receive an UNPREPARED response, re-prepare, and update its local metadata=
. But other clients might miss it entirely (the MD5 hasn't changed), and th=
ey will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, cl=
ientA and clientB both have a cache of the metadata (columns b and c) local=
ly
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED respon=
se, re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*=E2=80=99s cache again, with the same md=
5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has b=
een populated again, the query succeeds. But clientB still has not updated =
its metadata, it=E2=80=99s still (b,c)
> One solution that was suggested is to include a hash of the result set me=
tadata in the md5. This way the md5 would change at step 3, and any client =
using the old md5 would get an UNPREPARED, regardless of whether another cl=
ient already reprepared.


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