David Barrett <[EMAIL PROTECTED]> wrote: > There is a single table (bar) with a single column (foo) with a single > row containing the integer value "1". Two processes (A and B) have > opened the database in READWRITE mode. They both try to atomically > increment the value at the same time. What happens? > > 1) [Process A] BEGIN TRANSACTION > 2) [Process B] BEGIN TRANSACTION > 3) [A] SELECT foo FROM bar > (A acquires a SHARED lock) > 4) [B] SELECT foo FROM bar > (B acquires a SHARED lock) > 5) [A] UPDATE bar SET foo=2 > (A acquires the RESERVED lock) > 6) [B] UPDATE bar SET foo=2 > (? query fails, B's transaction aborted, SHARED lock released?)
SQLite detects deadlock situation. The call trying to execute the update statement fails immediately with SQLITE_BUSY error. Neither transaction releases its locks: to make progress, one of them has to explicitly roll back. > 7) [A] COMMIT > (A gets the EXCLUSIVE lock, writes, clears the lock) Unless B rolled back after getting an error on step 6, A will get the same error here. Why not simply execute "UPDATE bar SET foo=foo+1;"? Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
