Mutate CassStatement immediately after cass_session_execute

[Joe Karlin]

Can I mutate (i.e. bind to) a CassStatement immediately after calling cass_session_execute (i.e. before waiting on the returned CassFuture)?

[Sandeep Tamhankar]

No, that would introduce a race condition. Your statement might execute with or without the parameter bound.

Can you provide a little more context on why you'd want to do something like this?

[Joe Karlin]

On Thursday, March 2, 2017 at 4:42:14 PM UTC-5, Sandeep Tamhankar wrote:
> No, that would introduce a race condition. Your statement might execute with or without the parameter bound.
>
> Can you provide a little more context on why you'd want to do something like this?

I am testing, for our primary select statement, query response time and throughput for increasing numbers of parallel queries.

I'd like to execute the same select statement with different parameters multiple times in parallel.

For the time being, I've created a statement pool. I prepare a statement per desired parallel execution, and I wait to reuse statements until the related execution future is ready (as indicated when the set callback is called).

Thoughts?

[Michael Penick]

+1 That's a good approach if you want to avoid the overhead of reallocating CassStatement objects.

--
You received this message because you are subscribed to the Google Groups "DataStax C++ Driver for Apache Cassandra User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cpp-driver-user+unsubscribe@lists.datastax.com.