> > 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.
I have some additional questions, just for consistency of my knowledge. So, please, don't irritate. 1. Any single SQL command in SQLite start transaction. Any write operation should start with getting shared lock. So question is shared lock == read lock? if its true, then two inserts is transactions which starts with read lock... So it's still possible situation like above. 2. What will be if we have SQL command like this "UPDATE ... SELECT" ? In this case we have explicitly calls to SELECT which should get read lock. -- 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
