On Fri, Aug 04, 2017 at 08:50:05AM +0200, Luc DAVID wrote: > sqlite has WAL mode for better concurrency and this could maybe be used to > extend the number of writters: > > Do you think it would be possible to create a > MyDb.WAL001...MyDb.WAL.002...MyDb.WAL.nnn when a write operation is > currently running in order to allow more writers? > > The sqlite engine would then take care of dealing with all the WAL files > when reading data, backup...etc
WAL mode still ends up having no read concurrency when it's time to checkpoint the WAL. The same would happen with this concept. I don't think this works well. Other approaches will work better. One would be to have a server process, with the SQLite3 API transparently using IPC to talk to it. Or else a single-process DB (connections from only one process allowed at any time) where internal thread synchronization could be used to manage locks (on rows/pages and a log used to ultimately put together a final transaction in the background so that other threads can keep making progress). Doing this sort of thing with multiple processes gets tricky fast, requiring shared memory, mutexes on shared memory, ... IPC to a server process makes everything much simpler, but there is an IPC performance penalty. The server process model works very well for PostgreSQL though... Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
