Could you use PRAGMA data_version
before and after each read to see whether there have been any changes to the DB - not surehow this works in WAL mode? Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit -Forensic Toolkit for SQLite email from a work address for a fully functional demo licence On 24 November 2016 at 21:59, Florian Weimer <fwei...@redhat.com> wrote: > On 11/24/2016 10:41 PM, Howard Chu wrote: >> >> Florian Weimer wrote: >>> >>> 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? >> >> >> Seems like quite a lot of burden to go this route. SQLite has a much >> larger footprint than BDB, and much worse performance overall. > > > SQLite has zero footprint for us because central parts of the system use it > as well, and it is not likely to go away. We also use the full Transaction > Data Store, so the Berkeley DB shared object is about twice as large as the > SQLite object. > >> As a >> compromise you could use SQLightning, which replaces SQLite's Btree >> layer with LMDB. Since LMDB *does* allow readers that don't block >> writers. > > > How does it do that? Does LMDB perform lock-free optimistic reads and > retroactively verifies that the entire read operation was consistent? The > web page currently says that “readers need write access to locks and lock > file”: > > <http://lmdb.tech/doc/> > > The restriction on opening the database twice within the same process is > something which we would have to work around, too. > > I see you are working on eliminating the key size limit, which is nice. > > Thanks, > Florian > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
