cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
Date Thu, 19 May 2016 16:05:13 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291370#comment-15291370
] 

Tyler Hobbs commented on CASSANDRA-10786:
-----------------------------------------

I like the idea of using a separate hash/ID for the statement and the result set metadata
if we want to fix the "prepare storm" problem at the same time.

Overall, it seems like it would work like this:
* In response to a PREPARE message, the server returns a statement ID and a result set metadata
ID.
* When performing an EXECUTE, the driver sends both IDs.
* If the prepared statement ID isn't found, the server responds with an "unprepared" error,
and the driver needs to reprepare as usual.
* If the statement ID is found, but the metadata ID doesn't match, the server executes the
query and responds with a special results message.  This message contains the correct result
set metadata and its ID, the prepared statement ID, and a flag to indicate that it's doing
this.
* When the driver receives this special response, it replaces its internal result set metadata
with the new one from the response.

In the scenario Robert describes above (some nodes have seen a schema change, others haven't),
this would avoid repreparation of statements.  The driver might end up swapping its internal
result set metadata for the statement several times, but that's relatively inexpensive.

> 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)

Mime
View raw message