I got a Connection, and a Statement class.
The Connection class holds the Database Connection ODBC Handle.
The Statement class holds the Statement Handle, there can be multiple per Connection. It is made and destroyed each time a query must be done on the DB.
Now I'm just wondering.
I have a multithreaded application.
Is keeping one Connection for one DB enough for the whole application? Where the different threads will make Statements based on that one Connection.
Or is it better to keep a Connection per thread?
I have a multithreaded application.
Is keeping one Connection for one DB enough for the whole application? Where the different threads will make Statements based on that one Connection.
Or is it better to keep a Connection per thread?
First of all, the database documentation should explicitly state whether its ODBC driver is able to operate in multithreaded environment. If yes, the further design is up to you, i.e. you just try and see unless there's a recommendation to do not.
Typically database connection operation is not expensive too much, so you even may have a few connections in the same thread simultaneously.
Note that some DB's will charge for or have their license restrictions based on how many connections you make, so even for a multithreaded app, there may be motivations to do all your work on a single connection (in so far as your ODBC driver allows the actions you're doing to be multithreaded on a single connection).
Bookmarks