"Alexander Batyrshin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 1. Any single SQL command in SQLite start transaction.
Yes, unless part of an explicit transaction initiated with a BEGIN statement. > Any write > operation should start with getting shared lock. No, write operations start by acquiring a reserved lock. > 2. What will be if we have SQL command like this "UPDATE ... SELECT" ? It's a write operation and it starts by acquiring a reserved lock. Precisely because of statements like this, a reserved lock is compatible with shared locks. You may execute an UPDATE statement, but it might have to do some reading before it's ready to write, and meanwhile you don't want to lock out other readers. Reserved lock indicates that a transaction will be writing at some point in the future. It must promote to an exclusive lock before actually writing to the physical file. > In this case we have explicitly calls to SELECT which should get read > lock. No, you don't run a SELECT statement. You run an UPDATE statement. The fact that the statement contains a nested select is immaterial. Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
