Major From a forum discussion, a user reports that if they fire off a lot of async requests at once they end up preparing a large number of times. This indicates that there might be a synchronization problem during prepare if we're preparing multiple times. If the statement is the same it should prepare once and cache.
Since the actual prepare logic is expensive, it might make sense to index into whatever data structure we're using in the .NET client cache with a state that it's preparing, then backoff and retry from multiple callers.
Yeah, I agree. We would introduce latency on checking and waiting for prepared statements to be cached. We could maybe a option to wait, but I don't think it would be used much.
What the forum poster did, to prepare the statements ahead of the load test, is the best option. If an application has known statements, it could prepare them as part of start up to ensure they are ready for normal processing.
After further discussion with Jeff Morris and Matt Ingenthron we think that we should not introduce a blocking process to prevent multiple concurrent prepare requests as will introduce additional latency. We have agreed we will release note this scenario with a suggestion to prepare known expensive queries during application start where possible.
Yes, there is nothing stopping requests on multiple threads from doing the prepare. I suspect if we block on a large amount of callers, waiting for the prepare to complete, then you'll see some timeouts. That is probably the best option here.