Hello, If I understand the documentation right, the following SQL snippet can cause deadlocks when running multi-threaded, because both threads can acquire and hold the SHARED lock at the same time, but then no thread can get the EXCLUSIVE lock anymore (note that the SELECT and INSERT are meant to represent arbitrary read and write operations):
BEGIN DEFERRED; SELECT * FROM mytable; INSERT VALUES(42) INTO mytable; COMMIT; This can be fixed by using BEGIN IMMEDIATE instead. The following code does not have this problem, because every thread tries to directly get an EXCLUSIVE lock: BEGIN DEFERRED; INSERT VALUES(42) INTO mytable; INSERT VALUES(42+1) INTO mytable; COMMIT; However, since no thread attempts to get a SHARED LOCK anyway, this is equivalent to using BEGIN IMMEDIATE. Now I am wondering: in which situation do I actually want to use BEGIN DEFERRED? It seems to me that it either causes deadlocks, or, if it doesn't, it is equivalent to BEGIN IMMEDIATE anyway. 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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
