"Alexander Batyrshin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> Dropping the read lock is the same as rolling back the >> transaction. The first process can, in fact, do this. And >> the second process is waiting for the first process to do >> this. But the first process cannot do it automatically. The >> application must issue a "COMMIT" or "ROLLBACK" command >> to make it happen. > > For example, if 2 processes executes simple SQL INSERT commands and > gets situation like above, one of them can easily drop read lock and > wait for another one. There is no problem for this case.
Two concurrent inserts never result in a deadlock. For a deadlock to occur in SQLite, at least one transaction should start as a read-only (with a select statement) and later attempt to promote to read-write (with insert, update or delete statements). In this case you may get into a situation where the first transaction holds a shared lock and waits to promote it to reserved, and the second one holds a pending lock, wants to promote it to exclusive and waits for all readers (shared locks) to clear. Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
