[РЕШЕНО] connection pool плюсы и минусы

[Old]

http://www.prog.org.ru/topic_23820_0.html
http://www.prog.org.ru/topic_27817_0.html
http://www.prog.org.ru/topic_29697_0.html
http://www.prog.org.ru/topic_14426_0.html
http://www.prog.org.ru/topic_12552_0.html

[ballard]

Еще раз спасибо! на самом деле многое обсуждалось) проштудирую ссылки и выложу свое обновленное решение

[ballard]

Но вы все усложняете, достаточно запустить воркеры и организовать для них одну очередь запросов, по мере освобождения воркеры будут брать запросы из очереди или заснут, пока не появятся новые запросы.
Организация таких очередей 100500 раз обсуждалась на форуме, поищите, там и примеры были.

Просмотрел ссылки, а так же проглядел раздел про многопоточности, но так и не получается сформировать цельное представление...
Как лучше организовать очередь? через semaphore? или через qqueue...
Как быть с воркерами? qtconcurrent + future как мне казалось подходят потому что позволяют организовать синхронную блокирующую функцию типа QSqlQuery executeQuery (const QString& query) {...} , если делать воркеры через qthread, например, то возврат результата можно реализовать только через сигналы-слоты...это не то, что нужно, хотя может быть я и ошибаюсь
Идеально было бы реализовать вариант с забором запросов из очереди и засыпанием, но здесь уже, вроде бы надо использовать qwaitcondition?
как-то разные части задачи делаются разными способами, а как их совместить пока не вижу...

[Old]

Как лучше организовать очередь? через semaphore? или через qqueue...

QList+QWaitCondition

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

А на что там остается смотреть?
Вот простейший пример очереди задач: http://www.prog.org.ru/index.php?topic=14426.msg95463#msg95463
Клиент(ы) в нее добавляют задания, а ворер(ы) достают и обрабатывают. Результат отдают через сигнал. Все это добро (очередь и нитки-воркеры) прячется за классом пул, в который можно добавлять запросы, а при получении ответа он эмитит сигнал.
Если нужны еще и синхронные запросы, то это делается не через воркеры, а синхронным запросом через отдельное подключение.

[ballard]

QList+QWaitCondition
А на что там остается смотреть?
Вот простейший пример очереди задач: http://www.prog.org.ru/index.php?topic=14426.msg95463#msg95463
Клиент(ы) в нее добавляют задания, а ворер(ы) достают и обрабатывают. Результат отдают через сигнал. Все это добро (очередь и нитки-воркеры) прячется за классом пул, в который можно добавлять запросы, а при получении ответа он эмитит сигнал.
Если нужны еще и синхронные запросы, то это делается не через воркеры, а синхронным запросом через отдельное подключение.

Спасибо! Т.е. я правильно понял, что либо пул, либо синхронный запрос?

[Old]

Спасибо! Т.е. я правильно понял, что либо пул, либо синхронный запрос?

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

[ballard]

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

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

[ballard]

Скорее, либо другие нити, либо синхронный запрос.

Можете еще вот эту фразу пояснить?

[Old]

Можете еще вот эту фразу пояснить?

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

[ballard]

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

Так вот и вопрос, есть ли способ организовать доступ выполнение синхронных запросов из разных потоков при помощи одного коннекшена, либо их набора с очередью для запросов...?

[Old]

Так вот и вопрос, есть ли способ организовать доступ выполнение синхронных запросов из разных потоков при помощи одного коннекшена, либо их набора с очередью для запросов...?

Сформулируйте, что понимаете под синхронными запросами.
Вы хотите выполнять серию запросов в определенном порядке? Тогда самое просто изменить ваш пул так, что бы он принимал не строку запроса, а массив строк (QStringList). А нитки-воркеры в цикле их выполняли.

[ballard]

Сформулируйте, что понимаете под синхронными запросами.
Вы хотите выполнять серию запросов в определенном порядке? Тогда самое просто изменить ваш пул так, что бы он принимал не строку запроса, а массив строк (QStringList). А нитки-воркеры в цикле их выполняли.

Я хочу сделать так, чтобы у моего пула, хотя это скорее уже не пул, а что-то большее, но не суть, был один публичный метод, типа:

Код:

QSqlQuery executeQuery(const QString &query);

который бы располагал такие запросы в очереди, а свободные воркеры их из нее забирали и обрабатывали.

При этом мне нужна возможность обращаться к пулу из разных потоков.

Я, в принципе, понимаю, как это сделать через сигнал-слот, но можно ли сделать метод возвращающий результаты запроса в таком виде пока не пойму...

[Old]

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

Ну так мы сейчас именно это и обсуждаем. Для этого нужны несколько рабочих ниток и очередь запросов (QList+QWaitCondition).
Все.

Я, в принципе, понимаю, как это сделать через сигнал-слот, но можно ли сделать метод возвращающий результаты запроса в таком виде пока не пойму...

А результат можно возвращать с помощью сигнала, добавив каждому запросу некий ID.

Код

C++ (Qt)
public:
    ID    executeQuery( const QString &query );    // Возвращает ID запроса
 
signals:
    void    queryFinished( ID id, const QSqlQuery &result );    // Испускается после выполнения запроса
 

[ballard]

Ну так мы сейчас именно это и обсуждаем. Для этого нужны несколько рабочих ниток и очередь запросов (QList+QWaitCondition).
Все.

А результат можно возвращать с помощью сигнала, добавив каждому запросу некий ID.

Код

C++ (Qt)
public:
    ID    executeQuery( const QString &query );    // Возвращает ID запроса
 
signals:
    void    queryFinished( ID id, const QSqlQuery &result );    // Испускается после выполнения запроса
 

Сейчас еще такая мысль есть, а что если мне в QList заданий для воркеров класть QFuture, и пусть у меня при вызове из одного потока запрос будет блокирующий, т.е. пока текущий не завершится следующий не поступит на исполнение? а из других потоков задания будут проходить

[Old]

Если вы блокируете текущую нить на время выполнения запроса, то не понятно для чего его выполнять в другой нитке. Ну и выполняйте этот запрос сразу в текущей?