Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 5 Jul 2016 22:04:11 +0000 (UTC)
From: "Tyler Hobbs (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12916909.1448876954000.30874.1467756251445@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: Tue, 05 Jul 2016 22:04:13 -0000


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

Tyler Hobbs commented on CASSANDRA-10786:
-----------------------------------------

I also agree that 1) is the better option, and I think the "beta" flag is a=
 good way to expose in-progress protocol versions for driver testing and de=
velopment.

I've created CASSANDRA-12142 to implement the beta flag.  It would be nice =
to implement that prior to committing this ticket so that we can utilize th=
e beta flag for this new protocol feature.  However, if anybody feels stron=
gly that we should go ahead and commit this first, I won't object.

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