Доброго времени суток.

В новом проекте появилась потребность в организации подключения к БД в отдельном потоке с возможностью использования оной в множестве других потоков.

Раньше данную задачу решали создание обертки работающий через сигналы и слоты с БД в другом потоке (либо без потока), но при этом не было потребностей организовывать доступ к одному конекту БД сразу из нескольких потоков.
Сейчас появилась потребность в переработке (написания с нуля) такой обертки которая позволит реализовать многопоточную работу с БД. При этом главным условием является использование только одного коннекта к БД без возможности создания множественных коннектов с теми же параметрами.
Следовательно возник вопрос: а нет ли уже готовых решений которые можно позаимствовать? Ну или может подскажете каким образом это проще реализовать для Qt?)

Заранее спасибо.

White Owl,

Это первое, что пришло в голову. Но к сожалению такие обертки усложняют использование базового функционала QSqlQuery, по факту нужно написать аналог bind и bound.

rovan,

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

Ага, так и сделано, только основной поток он же GUI не сигнал ждет, а просто включает новый цикл обработки событий и холостит до сигнала завершения запроса.

White OwlheleoНо к сожалению такие обертки усложняют использование базового функционала QSqlQuery, по факту нужно написать аналог bind и bound.Вовсе нет.
Можно и без врапперов...

У тебя уже есть фоновая работа с БД? Как она организована?
Рабочий поток посылает в фоновый поток коннекта сообщение с sql запросом. Фоновый поток этот запрос отдает интерфейсному драйверу который и работает напрямую с СУБД. Дожидается ответа от этого интерфейсного драйвера и кидает рабочему потоку сигнал "готово". Потом по отдельному запросу отдает рабочему потоку резалтсет.
Так?

Теперь тебе достаточно в этот фоновый поток коннекта добавить индексированную очередь запросов. Тогда множество рабочих потоков смогут кидать запросы и получать в ответ индексы. Теперь объект работающий с СУБД может по очереди брать запросы из очереди, отправлять их в СУБД, а получив ответ ... Ну дальше уже варианты:
- кидать сигнал "готово" именно тому потоку который послал запрос (тогда при постановке запроса в очередь надо запоминать кто его послал).
- кидать широковещательный сигнал о готовности с добавлением в сигнал индекса. И рабочие потоки будут смотреть: мой индекс или не мой? Если мой - запрашивать резалтсет.

Это все хорошо до тех пор пока не появляется транзакция с begin, end и кучей запросов посередине в рамках работы одного из потоков, а следовательно тут не просто пул запросов и ответов по сигналам.

MasterZivЕщё раз, переосмыслим...

heleoВ новом проекте появилась потребность в организации подключения к БД в отдельном потоке



Именно подключаться к БД в отдельном потоке бессмысленно, это быстро, делается один раз -- можно сделать это в главном потоке.
(main)

heleoс возможностью использования оной в множестве других потоков.


Это уже более осмысленно, но соединение на время выполнения запроса всё равно будет занято, поэтому особенно эффективно разделять его не получится.

Лучше (на мой взглад) делать компоненту "пул соединений и очередь запросов на асинхронное выполнение в БД"

heleoСейчас появилась потребность в переработке (написания с нуля) такой обертки которая позволит реализовать многопоточную работу с БД. При этом главным условием является использование только одного коннекта к БД без возможности создания множественных коннектов с теми же параметрами.


Это какое-то странное условие. По коннекту на запрос создавать, конечно, глупо, но 5-10 коннектов вместо одного -- вовсе нет ничего страшного.

Ну тут по всей видимости я криво отписался. Конечно конект один на все время работы программы, создание нескольких конектов под одними и теми же параметрами login\password не допускается. Создается он по факту в main путем создания отдельного потока с БД.

White OwlheleoЭто все хорошо до тех пор пока не появляется транзакция с begin, end и кучей запросов посередине в рамках работы одного из потоков, а следовательно тут не просто пул запросов и ответов по сигналам.Ну почему же... Это тоже легко реализовать.
Если у тебя используются ручные транзакции, то можно организовать очередь очередей. Пришел тебе begin transaction - заводишь новую очередь для индивидуальных запросов и кладешь эту очередь в конец транзакционной очереди. А выполняющая процедура всегда работает только с "первой" транзакцией. Не важно сколько там транзакций уже начато - они все ждут пока "первая" не получит end transaction. Тогда эта очередь уничтожается и начинает обрабатываться следующая транзакция.

Ну прям мои же мысли. Осталось как всегда - только реализовать)

White OwlMasterZivИменно подключаться к БД в отдельном потоке бессмысленно, это быстро, делается один раз -- можно сделать это в главном потоке.
(main)Вообще-то смысл есть. Во всяком случае в Qt. Там есть странные проблемы по передаче одного коннекта из потока в поток. То есть, конкретно для модуля QtSql, чрезвычайно желательно создавать коннект в том же потоке в котором ты будешь с этим коннектом работать.
Конечно если не использовать QtSql, то можно сделать все более по человечески. Но увы...

MasterZivЭто какое-то странное условие. По коннекту на запрос создавать, конечно, глупо, но 5-10 коннектов вместо одного -- вовсе нет ничего страшного.Если мы работаем с современной SQL-образной базой, то ты прав. Там практически всегда уже есть встроенная поддержка множества коннектов и разделение запросов на пакеты, сессии и транзакции.
А вот если у heleo в качестве БД используется какой-нибудь DBF или набор текстовых файлов - тогда всю систему синхронизации доступа к монопольному ресурсу придется делать вручную.
Правда возникает вопрос почему бы не конвертировать базу во что-нибудь более удобное? Но...

Я даже добавлю, в документации прямо сказано, что "нельзя создавать коннект в одном потоке, а использовать его в другом".

rovan,

как ни странно, но ничего не нарыл, хотя и не так глыбко копал. Есть какие то наработки в репозиториях кут, но даже при первой оценке это совсем не то. В итоге проще развить\модернизировать уже имеющийся класс путем добавления очереди запросов, в том числе с приоритетами для организации транзакций. Только теперь нужно будет не напрямую обращаться к интерфейсу БД, а получать свой уникальный инстанс с которым и работать.

m_Sla, White Owl,

я думаю не стоит забывать то, что это делается для облегчения рабочего процесса и всю работу с блокировкой в готовой общедоступной компоненте нужно скрыть.
То что будет блокироваться поток не столь важно, операции записи в БД крайне незначительны по сравнению с той нагрузкой которая будет перед ними в потоке.
А по поводу блокировки: наличие транзакции в несколько запросов по любому будет требовать блокировки при работе с БД, тут ни куда не деться кроме как создать новое подключение.