The ODBC specification mandates that all drivers must be thread-safe, that is, drivers must not fail when database requests are made on separate threads. It is a common misperception that issuing requests on separate threads always results in improved throughput. Because of network transport and database server limitations, some drivers serialize threaded requests to the server to ensure thread safety.
The ODBC 3.0 specification does not provide a method to find out how a driver services threaded requests, although this information is useful to an application. All the Progress DataDirect forODBC drivers provide this information to the user through the SQLGetInfo information type 1028.
The result of calling SQLGetInfo with 1028 is a SQL_USMALLINT flag that denotes the session’s thread model. A return value of 0 denotes that the session is fully thread-enabled and that all requests use the threaded model. A return value of 1 denotes that the session is restricted at the connection level. Sessions of this type are fully thread-enabled when simultaneous threaded requests are made with statement handles that do not share the same connection handle. In this model, if multiple requests are made from the same connection, the first request received by the driver is processed immediately and all subsequent requests are serialized. A return value of 2 denotes that the session is thread-impaired and all requests are serialized by the driver.
If (rc == SQL_SUCCESS) {
// driver is a DataDirect driver that can report threading information
if (ThreadModel == 0)
// driver is unconditionally thread-enabled; application can take advantage of
// threading
else if (ThreadModel == 1)
// driver is thread-enabled when thread requests are from different connections
// some applications can take advantage of threading
else if (ThreadModel == 2)
// driver is thread-impaired; application should only use threads if it reduces
// program complexity
}
else
// driver is not guaranteed to be thread-safe; use threading at your own risk
