On 11/24/2016 02:54 PM, Richard Hipp wrote:
On 11/24/16, Florian Weimer <fwei...@redhat.com> wrote:
I'd like to replace the use of Berkeley DB in RPM with SQLite.
The scenario is special in the follow way. There is no database server,
all access goes directly to the database. Unprivileged users without
write access to the RPM database are expected to run read-only queries
against the database. Privileged users (basically, root) is expected to
use locking to exclude concurrent writers. But read-only users should
not be able to stop acquisition of a write lock.
Is there a way to do this with SQLite?
The readers can open the database using URI filenames
(https://www.sqlite.org/uri.html) with query parameters "mode=ro" and
"locking=0". That will prevent the readers from blocking the writer.
Thanks, this looks promising.
For the writers, can I use an external lock file (accessible only by
root), and specify “locking=0” as well? I need to avoid stalling on a
read lock on the database file because any process which can open the
file could create such a lock, thus blocking regular SQLite operation.
But, if a write happens in the middle of a read, the reader might see
inconsistent data and report SQLITE_CORRUPT. This is harmless in the
sense that the database file is not really corrupt (the reader is
merely seeing parts of the files from two different points in time)
and subsequent reads should still work. If you are unlucky, a write
that happens at the same time as a read might cause the reader to
return incorrect results, so the reader can never be 100% sure that
the answer it gets back is correct.
Could I use PRAGMA data_version to detect the case where there answer
might be silently incorrect?
How important is it to you that the reader always get a correct answer?
An incorrect answer or SQLITE_CORRUPT is borderline acceptable. Endless
loops or crashes would be bad.
I need to run a test how often the existing code gets a wrong answer. I
can't imagine that it always gets this right because Berkeley DB does
not really support this use case, either. Either readers block writers,
or there will be wrong data occasionally.
Thanks,
Florian
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
