cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
Date Tue, 21 Jun 2016 21:25:58 GMT


Tyler Hobbs commented on CASSANDRA-10786:

bq. We (java driver team) discussed this and we agree with taking the approach we've previously
taken, we can do a separate branch with this change, build a jar and include it with C* (in
the lib/ directory as currently done). We'll do some extra validation to make sure everything
is good from the driver side. After a driver has been formally released with those changes,
we would want to update C* to use that.

That sounds good to me.

bq. What is the timeline of this change? Will it be in 3.8 or 3.10?

This might be included in 3.8, but...

bq. Will this be the only change in for protocol v5 or will some of the tickets in CASSANDRA-9362
be included as well?

We probably want to wait for some of those other features before finalizing the v5 protocol.
 However, we can release with some of the v5 features implemented without actually allowing
v5 connections to be made.  For testing, we can use a special flag to allow v5 connections.
 With that in mind, I don't necessarily think we should make v5 whatever ends up in 3.8 --
we should get in the features we really care about and finalize v5 in whatever C* release
that happens to be.

[~slebresne] what do you think of the above? Is there anything in CASSANDRA-9362 that you
would particularly like to get into the v5 protocol?

> Include hash of result set metadata in prepared statement id
> ------------------------------------------------------------
>                 Key: CASSANDRA-10786
>                 URL:
>             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 prepared 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 will receive an UNPREPARED response,
re-prepare, and update its local metadata. But other clients might miss it entirely (the MD5
hasn't changed), and they will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, clientA and clientB
both have a cache of the metadata (columns b and c) locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, re-prepares
on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been populated
again, the query succeeds. But clientB still has not updated its metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set metadata 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 client already reprepared.

This message was sent by Atlassian JIRA

View raw message