[
https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169957#comment-13169957
]
Jonathan Ellis commented on CASSANDRA-2475:
-------------------------------------------
bq. To clarify, you're saying you're in favor of putting no constraints
whatsoever on the number of stored statements, and relying solely on clients to
free them up?
That's what I meant, yes.
bq. Does this change at all (the perceived likelihood) if the number were 1,000
instead of 51? Or 10,000?
If a client is doing it "right," then it will use pooled connections, each of
which will use PS for each query needed by the app. Hundreds or even thousands
isn't crazy. So I'd be okay with a limit of 10000 as "practically equivalent
to unlimited for all intents and purposes, but it might save you from a buggy
client."
> Prepared statements
> -------------------
>
> Key: CASSANDRA-2475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Affects Versions: 1.0.5
> Reporter: Eric Evans
> Assignee: Rick Shaw
> Priority: Minor
> Labels: cql
> Fix For: 1.1
>
> Attachments: 2475-v1.patch, 2475-v2.patch, 2475-v3.1.patch,
> 2475-v3.2-Thrift.patch, v1-0001-CASSANDRA-2475-prepared-statement-patch.txt,
> v1-0002-regenerated-thrift-java.txt,
> v2-0001-CASSANDRA-2475-rickshaw-2475-v3.1.patch.txt,
> v2-0002-rickshaw-2475-v3.2-Thrift.patch-w-changes.txt,
> v2-0003-eevans-increment-thrift-version-by-1-not-3.txt,
> v2-0004-eevans-misc-cleanups.txt,
> v2-0005-eevans-refactor-for-better-encapsulation-of-prepare.txt,
> v2-0006-eevans-log-queries-at-TRACE.txt,
> v2-0007-use-an-LRU-map-for-storage-of-prepared-statements.txt
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
