Nested statements and concurrency

[matthew-wozniczka]

How is concurrency (w.r.t. multithreading) managed between a statement and it's descendant nested statements?

When section 3.6.1 _(SQL_GD_CONCURRENT bit for SQL_GETDATAEXTENSIONS) says

If the driver reports SQL_GD_CONCURRENT, the driver supports concurrent fetching of multiple columns using SQLGetData and/or nested handles.

Does that imply multiple threads simultaneously fetching?

Even if SQL_GD_CONCURRENT isn't specified, the application could still attempt to use a statement concurrently with its parent.

I think a driver should be allowed to use the same lock(s) for a statement and all of its descendants (other than in the SQLCancel impl.). Currently, all activity on a statement is serialized, and adding nested statements as a way of looking at them shouldn't force us to relax this property.

This should be explicit in the spec (one way or another), as, based on application behaviour, it could lead to deadlocks. For example, SQLDisconnect returns SQLState HY010 when An asynchronously executing function was called for a StatementHandle associated with the ConnectionHandle and was still executing when SQLDisconnect was called.

[mikepizzo]

This wasn't intended to imply multi-threadedness of those calls, but to say that you could interleave calls to the parent with calls to the children (or other siblings). That said, I know that there are clients that would like to concurrently fetch via multiple threads. We shouldn't require drivers to support this, but if drivers want to support it, and clients want to use it, we should provide a way for the drivers to report that they do or do not (by default) support it.

[mikepizzo]

Added clarification to 3.6.1, "Note that SQL_GD_CONCURRENT does not imply that the driver supports multiple concurrent asynchronous requests associated with the same parent statement handle. The root statement handle defines the scope for concurrent asynchronous operations."