The main problem with multiple writers would be in conflict resolution, locking and deadlocks.
Imagine a simple accounting transactions "update accounts set value = value + 1 where ..." if run at the same time from 2 threads (or close enough), then if you do not have conflict resolution in place you may end up increase value by only 1 1) alice starts transaction 2) bob starts transaction 3) alice reads value, sees 10 4) bob reads value, sees 10 5) alice writes 10+1 6) bob writes 10+1 ooops.... And once you have more than one query, things become even more complicated. Even among full relational DBs, few manage these correctly. IME only PostgreSQL and Firebird handle these correctly by default, for Oracle or MSSQL you have to use special locking modes and transaction options with significant performance penalties. Eric On Fri, Aug 4, 2017 at 8:50 AM, Luc DAVID <lucdavid....@free.fr> wrote: > Hello, > > I was thinking about a possible solution for sqlite "only single writer is > allowed at the same time" and database lock. > > 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 > > The maximum of allowed writers could be set by a pragma or another mean > (when opening the db) > > It seems a simply way to boost sqlite concurrency. > > Am I wrong on this point ? > > Best Regards > > Luc > > _______________________________________________ > 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
