On 7/10/19 7:54 AM, Andy Bennett wrote: > Hi, > >>> Thanks for the detailed explanation of how it works. What I meant to >>> ask was "is there really a difference in the *semantics*?". i.e. from >>> the user perspective, can databases in the two different modes end up >>> in different states? >> >> My understanding is NO, as long as the same transactions complete. > > Thanks! That explanation is really great. > > >> In both cases, if a read transaction attempting to upgrade to a write >> transaction gets a busy, it needs to end the transaction and re-do its >> reads before it can do its write. > > This is assuming that you have the defauly busy handler engaged? > > Best wishes, > @ndy > A proper busy handler will wait when it make sense to get the needed locks, so you don't get spurious a spurious busy that you could just retry and be able to continue.
The fundamental issue would be a process that starts with just a read lock, and after reading some data realizes that it needs to update something based on what it read. If when upgrading to the write lock, you get a busy that tells you that you will NEVER be able to upgrade, then you need to close the transaction, and when you restart, you should forget the previous data you read (at least as it relates to what you might want to write) as it might have changed, so you need to read it again to be sure. -- Richard Damon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
