![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() ![]() |
![]() |
noneim |
![]()
Сообщение
#1
|
Новичок Группа: Новичок Сообщений: 1 Регистрация: 8.6.2010 Пользователь №: 1792 Спасибо сказали: 0 раз(а) Репутация: ![]() ![]() ![]() |
На данный момент есть программа, использующая подключение к БД sqlite:
Инициализация:
Далее в разных потоках:
Но недавно прочитал , что оказывается так нельзя делать. Хотя вроде бы тестил и под windows и под Linux, работало без багов. Интересует надежность такого применения, на данных момент демон нормально держит uptime несколько дней, но вдруг возникнут какие-нибудь неожиданные баги? |
|
|
Kagami |
![]()
Сообщение
#2
|
Старейший участник ![]() ![]() ![]() ![]() Группа: Участник Сообщений: 601 Регистрация: 2.2.2009 Пользователь №: 523 Спасибо сказали: 101 раз(а) Репутация: ![]() ![]() ![]() |
Ну, в принципе так делать можно. Просто SQLite может обрабатывать только один запрос на запись одновременно. Если в момент записи произойдет попытка еще одной записи в БД из другого потока, то этот второй поток просто будет заморожен пока первая операция записи не завершится.
|
|
|
512es |
![]()
Сообщение
#3
|
Участник ![]() ![]() Группа: Участник Сообщений: 135 Регистрация: 31.10.2008 Пользователь №: 407 Спасибо сказали: 5 раз(а) Репутация: ![]() ![]() ![]() |
Недавно проводил стресс тесты. Методом экспериментов выяснил что работать с одним соединением в двух потоках лучше, чем с двумя отдельными. Хотя в доках по Qt написано что этого делать нельзя..
На деле разница получается в том что, когда одно соединение используется, второй поток блокируется. А если несколько соединений с одним файлом базы то второй поток иногда получает отказ в выполнении запроса. Постгрес в нескольких потоках вообще начинает страшно глючить, а склайт работает... А по теме советую всётаки вывести работу с базой в отдельный поток, ака db writer, и присылать в него данные через сигналы и слоты в режиме очереди. Тогда работать будет вообще идеально. Тем более, если вдруг база не успеет записать данные до получения новых, они просто выстроятся в очередь и запишутся чуть позже, ничего не теряя. |
|
|
Litkevich Yuriy |
![]()
Сообщение
#4
|
![]() разработчик РЭА ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Сомодератор Сообщений: 9669 Регистрация: 9.1.2008 Из: Тюмень Пользователь №: 64 Спасибо сказали: 807 раз(а) Репутация: ![]() ![]() ![]() |
|
|
|
512es |
![]()
Сообщение
#5
|
Участник ![]() ![]() Группа: Участник Сообщений: 135 Регистрация: 31.10.2008 Пользователь №: 407 Спасибо сказали: 5 раз(а) Репутация: ![]() ![]() ![]() |
|
|
|
512es |
![]()
Сообщение
#6
|
Участник ![]() ![]() Группа: Участник Сообщений: 135 Регистрация: 31.10.2008 Пользователь №: 407 Спасибо сказали: 5 раз(а) Репутация: ![]() ![]() ![]() |
тыкс.. кажется я придумал способ получше. точнее лишь более корректный, чем шарить соединение на 2 потока.
чтобы не получать ошибку о том что бд занята можно указать значение таймаунта побольше. db.setConnectOptions("QSQLITE_BUSY_TIMEOUT=10000"); правда не факт что подвисший поток всётаки разлочит базу и главный поток запишет данные |
|
|
FireBlack |
![]()
Сообщение
#7
|
![]() Студент ![]() Группа: Участник Сообщений: 38 Регистрация: 17.10.2010 Из: г.Пенза Пользователь №: 2121 Спасибо сказали: 13 раз(а) Репутация: ![]() ![]() ![]() |
Недавно споткнулся о грабли многопоточности и QSQLite. Сначала не обратил внимание на документацию и использовал одно подключение QSqlDatabase в нескольких потоках. В результате приложение падало с "unhandled exception" то в qsqlite.dll, то в ntdll.dll. Причем могло упасть как через 10 минут стресс-теста, так и через 2 часа.
Проблему решил с помощью QSqlDatabase::cloneDatabase, выдавая каждому потоку свое подключение к базе. Чтобы избежать ошибки "database is locked" работу с SQL обвернул в мьютекс. |
|
|
![]() ![]() ![]() |
![]() |
|
Текстовая версия | Сейчас: 13.5.2025, 4:36 |