On Tue, Nov 29, 2016 at 10:10 AM, Mark Hamburg <mhamburg...@gmail.com> wrote: > On Nov 29, 2016, at 9:09 AM, Simon Slavin <slav...@bigfraud.org> wrote: >>> On 29 Nov 2016, at 4:18pm, Mark Hamburg <mhamburg...@gmail.com> wrote: >>> >>> Does this make sense? Does it seem useful? (It seems useful to me when I >>> see multi-megabyte WAL files.) >> >> Sorry, but I cannot spare the time right now to analyze the system you laid >> out. It usually takes half an hour to diagram out the read and write >> procedures and point out where multiple simultaneous ones don’t fit together. >> >> I can tell you that entire books are written about the difficulties of >> simultaneous access to a database, and that I’ve read too many of them. And >> that it has been proven many times that there’s no solution. You cannot >> design a system which (A) provides up-to-date data to readers (B) allows >> writers to get rid of their data immediately without ever locking up and (C) >> guarantees that earlier changes to the data are ’saved' before later >> changes, thus preserving uncorrupted data in the case of power-cuts, etc.. >> >> It is possible to implement a version if you drop one of the requirements. >> For example, you can have many simultaneous writers as long as you don’t >> need any readers. Or you can have many readers as long as you have only one >> writer and you don’t need readers to be completely up-to-date. >> >> You might like to read more about Brewer’s Theorem: >> >> <https://en.wikipedia.org/wiki/CAP_theorem> >> >> In the meantime, I’m glad that WAL mode seems to be useful for you, if you >> can cope with big journal files until all connections are closed, it’s a >> good solution. > > What I probably haven't accounted for is what it would take to do an > atomic/safe swap of the WAL files in my double WAL scenario. I need to give > that some more thought.
Don't do swaps. The issue is that WAL needs everyone to agree to reset to the front of the WAL file. The _A and _B files could have a serial number to differentiate which comes first. Then when the first file has no readers blocking, that file can be checkpointed to the main database. Then that file becomes available for future use. -scott _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
