"Igor Tandetnik" <[email protected]> writes: > Nikolaus Rath <[email protected]> wrote: >> What I think should be happening instead is this: >> >> - When executing statement 1, the main thread obtains a SHARED lock. >> >> - When executing statement 2, the main thread briefly obtains an >> EXCLUSIVE lock. After statement 2 is executed, the EXCLUSIVE lock is >> released and the main thread continues to hold the SHARED lock (since >> statement 1 is still active) > > No. A transaction can only upgrade its lock, but never downgrade, > until it's committed or rolled back (at which point it releases all > locks, of course). The lock level cannot get from EXCLUSIVE back to > SHARED. Otherwise, another connection would be able to read > uncommitted changes.
That makes perfect sense, but it's not in agreement with the way the test program behaves. If the main thread would keep the EXCLUSIVE lock after executing statement 2, it should not have any trouble executing statement 4. After statement 4 has been executed, the transaction is completed and the second thread should be able to execute statement 3. What actually happens is that statement 4 fails -- so at that point the main thread apparently believes that it does *not* have the exclusive lock anymore. Bug? Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
