Hi, I run several threads each having a shared cache connection to the same database containing a single table. No other threads or processes access this database. Half of the threads executes the following transaction:
BEGIN INSERT INSERT INSERT COMMIT Where each INSERT inserts a unique row into the table. The other half of the threads runs the following transaction: BEGIN SELECT UPDATE COMMIT Where SELECT selects a row from the table and UPDATE updates this same row. The threads use the sqlite3_unlock_notify() function to aid concurrency in a pretty much the same way as described on the "Using the sqlite3_unlock_notify() API"[1] page. As expected, I periodically get deadlocks (SQLITE_LOCKED return code from unlock_notify()) for the second transaction due to the read to write lock upgrade. But I also get deadlocks reported for the first transaction and this is something that I didn't expect to happen. My reasoning is that this transaction tries to get the write lock right away so I don't see how it can be blocking some other transaction. Can someone explain this? The first transaction behaves as if, for some reason, it first obtained the read lock and then tried to upgrade it to the write lock. But this doesn't seem to be the case -- I tried to run just the first transaction in multiple threads and there are no deadlocks. Any ideas would be much appreciated. [1] http://www.sqlite.org/unlock_notify.html Boris _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
