This is more rambling than anything else. I hope I'm reasonably coherent before coffee...
Instead of keeping an "undo" journal- consider using a "changes" journal-- each writer could use it's own journal then only at commit would each worker actually start making changes to the database. DEFER_WRITES isn't necessary; the changes journal could have information in it diverting certain tables/rows/pages for THIS WRITER ONLY so that selects can get information about earlier inserts/deletes/updates. No other writer needs access to this information until committing. Note that these changes will contain not only the values they are storing, but some kind of hash of the original value. This is used to detect whether or not two processes will UPDATE the same value. To make this simple, COMMIT should be allowed to fail (with no changes made). ROWID needs special assistance- There wasn't any mention of this on concurrency.html but what happens if two writers INSERT at the same time? Would they get the same ROWID? What if the user calls last_insert_rowid() or whatever? Ideally, ROWID should be allocated as soon as we SEE the INSERT. It shouldn't matter much if we just lost a ROWID-- they're relatively cheap on 32-bit platforms... If the database format changes, they're even cheaper on 64-bit platforms... On Sat, 2003-11-22 at 09:09, D. Richard Hipp wrote: > Feedback is requested on the paper found at: > > http://www.sqlite.org/concurrency.html > > Your analysis and ideas will help to make SQLite a > better database engine. Thanks. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
