On 31 Jul 2019, at 5:04pm, Larry Brasfield <brasfield.la...@gmail.com> wrote:
> I do not personally see the benefit of moving the repeatable read guarantee > to the BEGIN point rather than the first database read after the BEGIN > because only fully committed transactions will be visible anyway -- … I can imagine two programs, or two processes, might be communicating in some other way in addition to passing data through a SQLite database. So they need synchrony. Consider a bank which takes an audit every day at close-of-business. This might be declared to be 5pm. However, accounts are continued to be debited and credited all night, due to interest being added, ATM transactions, etc.. Nevertheless, the audit needs to see a snapshot as of 5pm. Of course, no bank would be using SQLite for this purpose, because a bank would be using a server/client DBMS. But you get the idea. But I think the BEGIN command can be retrofitted without breaking backward compatibility. The words WRITE and IMMEDIATE should be seen as options. WRITE means that you want a write lock as well as a read lock. IMMEDIATE means that you want it now, rather than when the first command of the transaction requires a lock. Use neither, either, or both. And EXCLUSIVE gets parsed as IMMEDIATE WRITE. Thus existing programs continue to do the same thing they always did. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
