On Apr 14, 2008, at 12:57 PM, Shawn Wilsher wrote:
>> Are you using a shared cache? You can get also get SQLITE_LOCKED
>> when
>> using a shared cache. See section 2.2 of
>> <http://www.sqlite.org/sharedcache.html>.
>>
>> I've not used a shared cache myself. One day I was wondering if I
>> needed to worry about handling SQLITE_LOCKED errors and I came across
>> that page. Are these the only times you can get SQLITE_LOCKED
>> errors?
> Ah-ha! We are in fact using the shared cache, which probably explains
> this. Any reason why SQLITE_LOCKED is returned instead of
> SQLITE_BUSY? With SQLITE_BUSY you can keep retrying until you decide
> to give up, or until it works, but you can't do that with
> SQLITE_LOCKED.
>
You can disable much of the SQLITE_LOCKED behavior using
PRAGMA read_uncommitted=ON;
In that case one thread will be able to read uncommited
changes made by a second thread. Turning on uncommitted
read will prevent writer and readers from blocking one another.
But you still won't be able to have two or more connections writing
at the same time. Nor will you be able to DROP a table out from
under a reader.
I am not aware of any reason why you cannot retry an SQLITE_LOCKED
error after a delay, however. Have you actually tried doing that?
Is it giving you trouble?
D. Richard Hipp
[EMAIL PROTECTED]
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
