Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 30 May 2016 13:53:12 +0000 (UTC)
From: "Alex Petrov (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12916909.1448876954000.331790.1464616392996@Atlassian.JIRA>
In-Reply-To: <JIRA.12916909.1448876954000@Atlassian.JIRA>
References: <JIRA.12916909.1448876954000@Atlassian.JIRA> <JIRA.12916909.1448876954569@arcas>
Subject: [jira] [Commented] (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: Mon, 30 May 2016 13:53:15 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15306686#comment-15306686 ]=20

Alex Petrov commented on CASSANDRA-10786:
-----------------------------------------

I've sketched the protocol changes from v4 [here|https://github.com/ifesdje=
en/cassandra/commit/3bf78daccbadb33d0368f32cc6ef4f8de1a32131] as described =
by [~thobbs]. I'll proceed with the mentioned changes.

> 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)