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
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
