> If there is a timeout and it is set to 0 by default then that it is not > very useful.
It's indeed so and it's useful in some cases. And you know, everything can be tested pretty easily. Just make some test database and execute in one terminal: sqlite> create table t (a); sqlite> begin; sqlite> select * from t; Then in other terminal: sqlite> .timeout 10000 sqlite> insert into t values (1); SQL error: database is locked And you'll see that before 'database is locked' appears shell will wait for 10 seconds. If while it waits you make commit in the first terminal then insert will succeed. And about your earlier discussion about locks: when connection has RESERVED or PENDING lock and it tries to propagate it to EXCLUSIVE it waits for busy_timeout and if still unsuccessful then it returns SQLITE_BUSY to the caller (or message 'database is locked' in the shell). If somebody locked database with PENDING or EXCLUSIVE lock and you're trying to get SHARED lock then SQLite will again wait for busy_timeout and if SHARED lock cannot be acquired yet then you will get SQLITE_BUSY or 'database is locked' message. Pavel On Wed, Oct 14, 2009 at 2:23 PM, priimak <prii...@stanford.edu> wrote: > Simon Slavin wrote: >> On 14 Oct 2009, at 5:39am, Dmitri Priimak wrote: >> >> >>> Yes, I understood that, but the impression I got is that SELECT will >>> place shared lock on the database. While INSERT or UPDATE will first >>> place PENDING lock indicating that it wants to write. >>> >> >> Okay, I see what you mean. I don't know how long the write process >> will wait for the shared lock to be released before returning an error >> message. If it ever gives up, that is. If it never gives up, a note >> from the developers on what >> >> >>>> database is locked >>>> >> >> means would be useful, since if it never gives up there's never any >> reason to generate that error message. I assume there's a timeout >> setting somewhere you can change but I see no PRAGMAs about timeout. >> > If there is a timeout and it is set to 0 by default then that it is not > very useful. > Moreover this http://www.sqlite.org/faq.html#q5 says > > "Multiple processes can have the same database open at the same > time. Multiple processes can be doing a SELECT at the same time. But > only one process can be making changes to the database at any moment in > time, however." > > Which does not seem to be true. > >> Googling on 'sqlite database is locked' suggests that other people >> have discussed this problem. > Well. One common "solution" is to copy database file apply changes > and then copy it back or to apply changes only to 1.db then copy it > to 2.db which would only be used for reading. This however is not > much of a solution and I have been actually doing just that, but the > file is getting bigger and bigger and copying it over is not an option > anymore since it takes too much time and IO, which is not good for > other processes running on that machine. And it also have effect on > latency between application of changes to the database and making > those changes available for querying. > > -- > Dmitri Priimak > _______________________________________________ > 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
