[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289228#comment-15289228
]
Andy Tolbert commented on CASSANDRA-10786:
------------------------------------------
With the issue that [~ifesdjeen] described on the driver end, there are some
things to worry about:
# this will be an issue in the case where a user has an older client install
with a newer C* install and they have this case where altering a table causes
the prepared statement hash to change, causing the repeating prepare as
described.
# this could also be a problem for cases of a cluster with mixed versions. If
you have some nodes at a newer version using this calculation, and others using
the previous calculation you will get different prepared ids depending on which
node you hit. Depending on the driver implementation this could be an issue.
What do you think about the possibility of tying prepared statement id
calculation to protocol versions? This way older clients that don't know to
handle such a case where the prepared id can change will continue to work, and
newer clients can be updated to support these scenarios as part of also
supporting a new protocol version (as [~ifesdjeen] is doing for the java
driver). This also would solve #2. The downside of tying this change to a
protocol version bump is that I imagine it defers this change quite a bit, and
this fix would be really nice to have as it will fix a problem a lot of users
have run into.
> 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
> 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)
