[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-10786:
------------------------------------
Status: Patch Available (was: Open)
What I've done was simply re-preparing and having try/catch around. But I think
you're right, it might be too error-prone to do it that way. It might be better
to let users re-prepare the very first statement and let the rest be handled
through the new {{Rows}}.
The patch is located here. Test failure for
{{UserTypesTest#testAlteringUserTypeNestedWithinNonFrozenMap}} even though
looks related, was failing on trunk, the patch for it is submitted
[here|https://issues.apache.org/jira/browse/CASSANDRA-12010]. The other tests
seem unrelated and are failing on trunk, too.
Please note that the patched binary for the driver was updated in tree, for
test purposes.
Test runs:
|[trunk|https://github.com/ifesdjeen/cassandra/tree/10786-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-10756-trunk-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-10786-trunk-dtest/]|
And patch for the driver is located
[here|https://github.com/ifesdjeen/java-driver/tree/10786-v5].
> 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)
