Try your test using a "begin Immediate" instead of begin. A write lock is not taken out until the very last moment (ie a spill to disk or commit).
Lior Okman <[EMAIL PROTECTED]> wrote: Hi, I'm using SQLite3 version 3.4.2 (latest in Debian testing and unstable), and I have a scenario using transactions in SQLite3 that is a bit counter-intuitive. I open an SQLite3 database from two terminals. In the first terminal I run the following SQLs: > $ sqlite3 test.db > SQLite version 3.4.2 > Enter ".help" for instructions > sqlite> create table a (id integer not null primary key); > sqlite> begin; > sqlite> insert into a values (null); > sqlite> insert into a values (null); In the second terminal, I run the following SQLS: > $ sqlite3 test.db > SQLite version 3.4.2 > Enter ".help" for instructions > sqlite> begin; > sqlite> insert into a values (null); > SQL error: database is locked I go back to the first terminal at this stage and I try to end the transaction using commit: > sqlite> commit; > SQL error: database is locked At this point, I can't commit the transaction in the first terminal, until I run a commit in the second terminal, even though the first terminal is the one with the active transaction, and the second terminal shouldn't have any effect on the active transaction. This behaviour varies, depending on the filesystem type on which the sqlite database file is created in. If I use reiserfs, it sometimes takes a long while until I can commit from any of the terminals. In ext3, this is usually resolved after retrying the commit a few times in both terminals. In tmpfs, there is never any issue, the first terminal can always commit. What am I missing here? Is this behaviour the expected one? Thanks, Lior ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
