Использование соединения QSqlDatabase в QtConcurrent :: run (пул псевдо-соединений)

Мое решение состоит в использовании QtConcurrent с пользовательским пулом потоков, который не уничтожает его потоки. И в каждом контексте потока я создаю выделенное QSqlDatabase соединение с этим именем потока в качестве имени соединения, так что каждый поток получает одно и то же соединение каждый раз, когда ему нужно поговорить с базой данных.

Настройка:

mThreadPool = new QThreadPool(this);
// keep threads indefinitely so we don't loose QSqlDatabase connections:
mThreadPool->setExpiryTimeout(-1);
mThreadPool->setMaxThreadCount(10); /* equivalent to 10 connections */

qDebug() << "Maximum connection count is "
         << mThreadPool->maxThreadCount();

Destructor:

// remove the runnables that are not yet started
mThreadPool->clear();
// wait for running threads to finish (blocks)
delete mThreadPool;

Пример API-реализации, возвращающий будущее, которое может использоваться для получения данных из базы данных, когда она доступна:

QFuture<QList<ArticleCategory> *> 
DatabaseService::fetchAllArticleCategories() const
{
    return QtConcurrent::run(mThreadPool, 
&DatabaseService::fetchAllArticleCategoriesWorker, mConnParameters);
}

Обратите внимание, что мое решение не управляет создаваемыми им объектами. Код вызова должен управлять этой памятью (QList, возвращенный выше).

Сопровождающая функция рабочего потока:

QList<ArticleCategory> *DatabaseService::fetchAllArticleCategoriesWorker(const DatabaseConnectionParameters &dbconparams)
{
    try {
        setupThread(dbconparams);
    } catch (exceptions::DatabaseServiceGeneralException &e) {
        qDebug() << e.getMessage();
        return nullptr;
    }

    QString threadName = QThread::currentThread()->objectName();
    QSqlDatabase db    = QSqlDatabase::database(threadName, false);

    if (db.isValid() && db.open()) {
        QSqlQuery q(db);
        q.setForwardOnly(true);
        // ...
    }
// else return nullptr
// ...
}

Если вы заметили, setupThread всегда вызывается в начале рабочего, который в основном поддерживает соединение с базой данных для вызывающего потока:

void DatabaseService::setupThread(const DatabaseConnectionParameters &connParams)
{
    utilities::initializeThreadName(); // just sets a QObject name for this thread

    auto thisThreadsName = QThread::currentThread()->objectName();

    // check if this thread already has a connection to a database:
    if (!QSqlDatabase::contains(thisThreadsName)) {
        if (!utilities::openDatabaseConnection(thisThreadsName, connParams))
        {
            qDebug() << "Thread"
                    << thisThreadsName
                    << "could not create database connection:"
                    << QSqlDatabase::database(thisThreadsName, false).lastError().text();
        }
        else
        {
            qDebug() << "Thread"
                    << thisThreadsName
                    << "successfully created a database connection.";
        }
    }
}

Эта статья мне очень помогла Асинхронный доступ к базе данных с Qt 4.x. Я думаю, что построение рабочего объекта в потоке и использование очередного соединения для вызова его слотов лучше, чем запуск новых событий и отправка их в поток. Вы можете загрузить образцы файлов из эту ссылку.

IIRC правильно, эта проблема имеет гораздо больше, чем для бэкэнда, чем Qt. Например, в прошлом - по-прежнему возможно - PostgreSQL требовал, чтобы каждый поток имел свое собственное соединение, но MySQL имел другие способы работы с потоковой обработкой. Пока вы играли по правилам бэкэнда, все работало нормально.

В прошлом для PostgreSQL я создал систему, в которой я бы нажал QSqlQuery в очередь, а другой поток очистил очередь, выполнил запрос и передал sqlresult обратно. Это было прекрасно, пока я всегда использовал одно и то же "резьбовое" соединение. Не имело значения, что я создал соединение в основном потоке, это имело значение только тогда, когда настало время для выполнения.

QtConcurrent был бы хорошим подходом для этой системы, хотя на самом деле только один раз. Тем не менее, это освободит основной поток.

Возможно, вы можете создать очередь соединений. Когда ваша функция выполняется, она вытягивает соединения из очереди, запускает запрос и добавляет его в конец очереди после завершения запроса. Это обеспечит использование только одного соединения для каждого потока. Хотя это не обязательно один и тот же поток для каждого подключения.

Опять же, это действительно зависит от бэкэнд. Проверьте документацию разработчика для базы данных на потоки и убедитесь, что вы соблюдаете эти правила.