0

I have a weird behaviour on my application using QSqlDatabase.

This is the simple code i'm using:

QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL", QString::number(this->m_id));
db.setHostName(SERVER_DATABASE_DATABASE_HOST);
db.setDatabaseName(SERVER_DATABASE_DATABASE_NAME);
db.setUserName(SERVER_DATABASE_USERNAME);
db.setPassword(SERVER_DATABASE_PASSWORD);
if( !db.open() ){
   ...
} 
...

This snippet of code is executed inside the run() method of a QRunnable and i have n(n~20) of those Task that run asynchronusly without problems(no duplicated db connections, the connections are removed, ecc..).

The problem is that, after a lot of iteration, the execution crash.

The crash is replicable but not deterministic.

I tryied to run the application in debug mode but the debugger, stop at the line where i call the db.open() function, whitout further information(no stack trace, no signal).

My system specification:

  • MySQL v5.7.17 (community edition)
  • Mac OSX 10.11.6
  • Qt 5.7.0

Any suggestion is very appreciated

BEPP1
  • 945
  • 2
  • 11
  • 15
  • Why do you open the database with each thread ? Why not pass a pointer to your Database (opened 1 time), then process whatever data you need ? – Elcan Jan 27 '17 at 11:00
  • @FlorentUguet , because a database connection can only be used from the thread that created it, see [here](https://doc.qt.io/qt-5/threads-modules.html#threads-and-the-sql-module). How exactly are you ensuring uniqueness of `this->m_id`? Can you provide an [MCVE](https://stackoverflow.com/help/mcve)? – Mike Jan 27 '17 at 11:18
  • Although I really think that the Qt SQL module is not best suited to be used from a thread pool. Do you really need to do that? – Mike Jan 27 '17 at 11:19
  • @Mike uniqueness of m_id in ensured by the main thread(Server) who generates the unique id on the client incoming connection and keeps a structure of the ids.(removing them on the client disconnect slot) what database would you suggest to use? – BEPP1 Jan 27 '17 at 11:27
  • The problem does not lie in using MySQL. **Do you really need a new thread for each client connection?** will the processor be really busy for each client? In most cases, there is no need to use a thread for each client. just use the asynchronous functions that Qt provides. – Mike Jan 27 '17 at 11:42
  • You suggest to make the connection on the Server(main thread) and then the clients ask to the server to make the query for them? In this case waiting the responses from the server( which will be queued since will be executed on a single thread) will make the client's task slower since the client has to wait the answers from the server. This is why i choosed this architecutre. – BEPP1 Jan 27 '17 at 11:53
  • Yes, I would suggest to move everything to the main thread. And only if there is some kind of heavy computation, perform that computation only in the thread pool (using `QRunnable`) and report the result back to the main thread. – Mike Jan 27 '17 at 11:56
  • Also, note that, your current approach is not very good in using the thread pool. Say you have 100 `QRunnable`s being executed on a `QThreadPool` of 8 threads, **your approach will cause 100 database connections** to be added and removed. While it would be much better if you had **only 8 database connections** (a connection for each thread in the thread pool) that were used across all `QRunnable`s (since all connections are done to the same database). – Mike Jan 27 '17 at 12:00
  • Thanks a lot for your help, very appreciate! Regarding the open connections in your example I don't understand because I made the connections on the function "run()" in the client and this one should be executed only when the pool starts the QRunnable. This connection is than removed when the QRunnable is destroied. I have the autodelete flag set to TRUE in the pool and I see that the disctructor is called correctly. The QRunnable task has a socket for communcation, and this process can be over 10 minutes. – BEPP1 Jan 27 '17 at 12:21
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/134181/discussion-between-mike-and-strstr). – Mike Jan 27 '17 at 12:30

0 Answers0