I got it. Fixed my program with "IMMEDIATE" transaction. On Fri, Apr 25, 2008 at 12:01 AM, Igor Tandetnik <[EMAIL PROTECTED]> wrote: > "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 >
-- Alexander Batyrshin aka bash bash = Biomechanica Artificial Sabotage Humanoid _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
