[ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289767#comment-15289767 ]
Robert Stupp commented on CASSANDRA-10786: ------------------------------------------ A v5 is fine IMO. But I'd suggest to include the v4-hash plus a hash over the references schema objects. This would make rolling upgrades more robust. The thing is that a statement can potentially reference UDFs which requires UDTs, which makes it difficult. OTOH the schema version would invalidate all pstsmts - even those that are not affected. Probably it's ok to just include the hash of the table instead of all referenced objects. Not sure on this. > 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, 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)