The most common reason to create another thread in a DB2 CLI application is so that a thread other than the one executing can be used to call SQLCancel() (to cancel a long running query for example).
| Note: | This method should be used for any platform which supports threads rather than using the asyncronous SQL model (which was designed for non-threaded operating systems such a Windows 3.1). If your application cannot make use of multi-threading then see "Asynchronous Execution of CLI". |
Most GUI based applications use threads in order to ensure that user interaction can be handled on a higher priority thread than other application tasks. The application can simply delegate one thread to run all DB2 CLI functions (with the exception of SQLCancel()). In this case there are no thread-related application design issues since only one thread will be accessing the data buffers that are used to interact with DB2 CLI.
Applications that use multiple connections, and are executing statements that may take some time to execute, should consider executing DB2 CLI functions on multiple threads to improve throughput. Such an application should follow standard practices for writing any multi-thread application, most notable those concerning sharing data buffers. The following section discusses in more detail what DB2 CLI guarantees and what the application must guarantee in order to write a more complex multi-threaded application.