[ https://issues.apache.org/jira/browse/CASSANDRA-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461934#comment-13461934 ]
Jonathan Ellis commented on CASSANDRA-4449: ------------------------------------------- bq. Changed in v2 to CLHM Can we update the {{Prepared query with ID %s not found}} IRE to explain that the problem is a client bug? i.e., that either # it didn't re-prepare across a server restart or # it prepared too many statements and the LRU ones dropped out bq. switch the hash used as statement ID to md5 Actually I don't see a reason to use something as heavyweight as MD5. Why not just use AtomicInteger? Bonus: this would allow fixing CQL2 as well while maintaining compatibility. > Make prepared statement global rather than connection based > ----------------------------------------------------------- > > Key: CASSANDRA-4449 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4449 > Project: Cassandra > Issue Type: Improvement > Reporter: Sylvain Lebresne > Assignee: Sylvain Lebresne > Labels: binary_protocol > Fix For: 1.2.0 beta 2 > > Attachments: 4449.txt, 4449-v2.txt > > > Currently, prepared statements are connection based. A client can only use a > prepared statement on the connection it prepared it on, and if you prepare > the same prepared statement on multiple connections, we'll keep multiple > times the same prepared statement. This is potentially inefficient but can > also be fairly painful for client libraries with pool of connections (a.k.a > all reasonable client library ever) as this means you need to make sure you > prepare statement on every connection of the pool, including the connection > that don't exist yet but might be created later. > This ticket suggests making prepared statement global (at least for CQL3), > i.e. move them out of ClientState. This will likely reduce the number of > stored statement on a given node quite a bit, since it's very likely that all > clients to a given node will prepare the same statements (and potentially on > all of their connection with the node). And given that prepared statement > identifiers are the hashCode() of the string, this should be fairly trivial. > I will note that while I think using a hash of the string as identifier is a > very good idea, I don't know if the default java hashCode() is good enough. > If that's a concern, maybe we should use a safer (bug longer) hash like md5 > or sha1. But we'd better do that now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira