Неблокирующий SQLite

Я вот не буду утверждать на все 100, но сикулайт, имея ОДИН файл для хранения одной «БД» не может быть не блокирующим, т.е. любое разовое изменение, какой-то апдейт, явно же должен лочить доступ к этому файлу. Так а в чем проблема то? даже если много и часто что-то меняется - вызов апдейта через обертку сикулайта не отпустит ранее чем сикулайт не отпустит свою блокирувку.

На этом же потоке крутится UI, не хотелось бы получать подвисоны при доступе к БД.

Тада по любому заворачивай в отдельный поток.

Или может какие-то отложенные апдейты делать или мудрить с очередью?

А обычное чтение? Оно тоже будет блокировки давать.

Не, чтение блокируется (ожидает пока отпустит) только когда кто-то уже в данный момент что-то апдейтит.

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

http://www.sqlite.org/asyncvfs.html

Deprecated

Где это сказано? Впрочем, мне все-равно.

Где это сказано?

http://www.sqlite.org/docs.html

«Asynchronous IO Mode This page describes the asynchronous IO extension developed alongside SQLite. Using asynchronous IO can cause SQLite to appear more responsive by delegating database writes to a background thread. NB: This extension is deprecated. WAL mode is recommended as a replacement.»

Кроме того, модуль давал лишь асинхронную запись.

Не, чтение блокируется (ожидает пока отпустит) только когда кто-то уже в данный момент что-то апдейтит.

Сами запросы могут быть достаточно долгими, если БД разрастётся.

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

Кстати, а что делать если пользак что-то там жмакнул в гуе и мы тут в отдельном потоке что-то пыхтим, но не успели до конца, а пользак уже закрыл/остановил прилагу?

В нормальных API на такой случай есть Cancellable, который позволяет отменить асинхронную операцию. А в случае SQLite, полагаю, нужно ждать пока не закончится операция.

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

WAL mode is recommended as a replacement.

Не подойдет?

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

http://www.sqlite.org/c3ref/interrupt.html

На этом же потоке крутится UI, не хотелось бы получать подвисоны при доступе к БД.

UI проще вынести в отдельный поток.

UI проще вынести в отдельный поток.

Ты хотел сказать - логику вынести в отдельные потоки.

А смысл? Там файловый io, а асинхронный файловый io в posix и в линукс делается через одно место, очевидно, в sqlite использовать такой API не стали. Если очень надо, то выноси в отдельный тред.

sqlite в конкурентной среде веселуха...

Пусть каждый процесс мутирует свои ресурсы, остальным - чтение.

libgda