[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337240#comment-15337240
]
Andy Tolbert edited comment on CASSANDRA-10786 at 6/17/16 11:54 PM:
--------------------------------------------------------------------
{quote}
What's our normal process for replacing the bundled Java driver when there's a
protocol version change? Andy Tolbert any preferences on how to handle the
review of the driver changes?
{quote}
Good question, I recall with protocol v4 and with C* 3.0 that there was a
period of time where a pre-released driver jar was put in lib which I think is
reasonable, but maybe there is a better way to do this, will discuss with the
team on Monday. There was [a
PR|https://github.com/datastax/java-driver/pull/675] for reviewing this, but we
will need to update it with the commit from [~ifesdjeen]'s
[branch|https://github.com/ifesdjeen/java-driver/tree/10786-v5].
was (Author: andrew.tolbert):
{quote}
What's our normal process for replacing the bundled Java driver when there's a
protocol version change? Andy Tolbert any preferences on how to handle the
review of the driver changes?
{quote}
Good question, I recall with protocol v4 and with C* 3.0 that there was a
period of time where a pre-released driver jar was put in lib which I think is
reasonable, but maybe there is a better way to do this, will discuss with the
team on Monday. There was [a
PR|https://github.com/datastax/java-driver/pull/675] for reviewing this, but we
will need to update it with the commit from
[~ifesdjeen's|https://github.com/ifesdjeen/java-driver/tree/10786-v5] branch.
> Include hash of result set metadata in prepared statement id
> ------------------------------------------------------------
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> 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
(v6.3.4#6332)
