On 7/2/2014 2:06 PM, Clemens Ladisch wrote:
Igor Tandetnik wrote:
On 7/2/2014 3:04 AM, Clemens Ladisch wrote:
If all else fails, one could try and simulate BEGIN IMMEDIATE by running
a dummy modifying statement right after BEGIN - e.g.
delete from table1 where 0;
Would this be atomic?
It would be part of the same transaction, wouldn't it?
In shared-cache mode, accesses from all threads are part of the same
transaction (as far as the database file is concerned).
SQL transactions are implemented on top of that.
File-level locks, yes - but not table-level locks, which is what appears
to be at issue here. Each connection to the shared cache maintains a
separate set of table-level locks.
In the OP's scenario, two connections to the same shared cache are
locking each other out - that can't possibly be due of file-level
locking (as you note, they both use the same underlying connection to
the file). Besides, a contention on file-level lock is reported as
SQLITE_BUSY, not SQLITE_LOCKED.
The hope is that issuing a "delete * from table1 where 0;" right after
BEGIN on a connection to a shared cache will cause that connection to
acquire a table-level write lock on table1 right from the start (or be
blocked trying), thus avoiding a deadlock scenario.
--
Igor Tandetnik
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
