> Is it correct behavior of sqlite that COMMIT will not proceed unless > no other transactions are present in the system?
No, SQLite never behaves like that. Probably you executed in the second thread some SELECT query (besides INSERT) and it wasn't finished yet by the time of COMMIT. In this situation it's documented for COMMIT to return SQLITE_BUSY. Pavel On Mon, Nov 15, 2010 at 7:38 AM, Bogdan Pilch <bpil7...@artax.karlin.mff.cuni.cz> wrote: > Hi, > I observe the following behavior: > Two threads processing the same transactions on a simple employee > table: employee(id,name,city,salary). > > THREAD 1 > ======== > BEGIN TRANSACTION; > insert into employees values (1025,'Bush','New York',1110000); > COMMIT TRANSACTION; > > THREAD 2 > ======== > BEGIN TRANSACTION; > insert into employees values (1024,'Obama','New York',1110000); > COMMIT TRANSACTION; > > Now, when thread 1 executes 'BEGIN TRANSACTION;' it goes to sleep/wait > and thread 2 executes two queries (begin and insert). > Then thread 2 wants to COMMIT, but SQLITE_BUSY is returned. > I suspect it is because thread 1 still has one transaction opened > (even though nothing has been read or written). > > Is it correct behavior of sqlite that COMMIT will not proceed unless > no other transactions are present in the system? > > > bogdan > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
