> -----Original Message----- > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of Igor Tandetnik > Sent: Friday, February 10, 2012 2:36 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Database locked in multi process scenario > > On 2/10/2012 12:29 PM, Sreekumar TP wrote: > > Can this situation be handled in sqlite - by upgrading the lock to a > > writer lock ? Since both applications use the same WAL file for read > > and writes, it shouldnt be a problem , because all changes will be in > > linear sequence ? > > Consider again: > > [1] BEGIN; > [1] SELECT balance from Accounts; (1) > > [2] BEGIN; > [2] SELECT balance from Accounts; (2) > [2] UPDATE Accounts SET balance = balance + 100; > [2] SELECT balance from Accounts; (3) > [2] COMMIT; > > [1] UPDATE Accounts SET balance = balance + 100; [1] SELECT balance > from Accounts; (4) [1] COMMIT; > > [3] SELECT balance from Accounts; (5) > > Statements are shown in the order they are submitted to SQLite. Numbers > in square brackets indicate individual connections. > > Let's suppose SQLite does everything the way you want (it's not quite > clear what it is you want exactly, so that's what I'm trying to > establish). I assume you expect this sequence of statements to succeed. > In this ideal world, what value of Accounts.balance should be observed > at points (1), (2), (3), (4) and (5), in your opinion?
Well.. in MSSQL that would work the way you think he expects. That is, if the initial balance is $100 (1) 100 (2) 100 (3) 200 (4) 300 (5) 300 MSSQL in its default serialization mode does not guarantee repeatable reads within a transaction. But, it provides locking hints to help enforce it when required. I'm guessing that sqlite does guarantee repeatable reads? Marc _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
