Re: [sqlite] SQLITE_LOCKED behavior

[Shawn Wilsher]

>  Did you call sqlite3_reset() before each retry?
Doing this fixed the issue.  Thanks!

Cheers,

Shawn
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLITE_LOCKED behavior

[Shawn Wilsher]

>  Did you call sqlite3_reset() before each retry?
Ah, I didn't realize I'd have to do that.  When I get SQLITE_BUSY
returned, I can just retry it, so I made the wrong assumption that
that would work in this case as well.

Cheers,

Shawn
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLITE_LOCKED behavior

[D. Richard Hipp]

On Apr 14, 2008, at 2:44 PM, Shawn Wilsher wrote:
>> 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?
> Attempting to retry after it being issues results in SQLITE_MISUSE
> being returned.
>

Did you call sqlite3_reset() before each retry?

D. Richard Hipp
[EMAIL PROTECTED]



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLITE_LOCKED behavior

[Shawn Wilsher]

>  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?
Attempting to retry after it being issues results in SQLITE_MISUSE
being returned.

Cheers,

Shawn
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLITE_LOCKED behavior

[D . Richard Hipp]

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
>> .
>>
>> 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

Re: [sqlite] SQLITE_LOCKED behavior

[Shawn Wilsher]

>  Are you using a shared cache?  You can get also get SQLITE_LOCKED when
>  using a shared cache.  See section 2.2 of
>  .
>
>  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.

Cheers,

Shawn
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLITE_LOCKED behavior

[D. Richard Hipp]

On Apr 13, 2008, at 3:01 AM, Tomas Lee wrote:
> On 2008 April 12 (Sat) 05:44:53pm PDT, Shawn Wilsher <[EMAIL PROTECTED] 
> > wrote:
>> When using SQLite 3.5.4.1 (a special branch cut for Mozilla, based
>> mostly off of 3.5.4 with some OS/2 fixes), I'm getting SQLITE_LOCKED
>> returned unexpectedly.  The documentation seems to indicate that I
>> should only be getting SQLITE_LOCKED if I'm calling sqlite3_exec
>> recursively writing to the same table.  However, it seems to me that
>> I'm having that happen when two different threads are trying to write
>> to the same table.  I would expect to get SQLITE_BUSY at this point,
>> but perhaps I'm misusing the API or have the wrong expectations.
>>
>> This is happening by using a different sqlite3 database pointers, one
>> for each thread.
>
> Are you using a shared cache?  You can get also get SQLITE_LOCKED when
> using a shared cache.  See section 2.2 of
> .
>
> 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?

If you are in the middle of a SELECT statement and from the same
database connection you try to DROP one of the tables that is being
read, the DROP statement will return SQLITE_LOCKED.


D. Richard Hipp
[EMAIL PROTECTED]



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLITE_LOCKED behavior

[Tomas Lee]

On 2008 April 12 (Sat) 05:44:53pm PDT, Shawn Wilsher <[EMAIL PROTECTED]> wrote:
> When using SQLite 3.5.4.1 (a special branch cut for Mozilla, based
> mostly off of 3.5.4 with some OS/2 fixes), I'm getting SQLITE_LOCKED
> returned unexpectedly.  The documentation seems to indicate that I
> should only be getting SQLITE_LOCKED if I'm calling sqlite3_exec
> recursively writing to the same table.  However, it seems to me that
> I'm having that happen when two different threads are trying to write
> to the same table.  I would expect to get SQLITE_BUSY at this point,
> but perhaps I'm misusing the API or have the wrong expectations.
> 
> This is happening by using a different sqlite3 database pointers, one
> for each thread.

Are you using a shared cache?  You can get also get SQLITE_LOCKED when
using a shared cache.  See section 2.2 of
.

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?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLITE_LOCKED behavior

[Shawn Wilsher]

Hey all,

When using SQLite 3.5.4.1 (a special branch cut for Mozilla, based
mostly off of 3.5.4 with some OS/2 fixes), I'm getting SQLITE_LOCKED
returned unexpectedly.  The documentation seems to indicate that I
should only be getting SQLITE_LOCKED if I'm calling sqlite3_exec
recursively writing to the same table.  However, it seems to me that
I'm having that happen when two different threads are trying to write
to the same table.  I would expect to get SQLITE_BUSY at this point,
but perhaps I'm misusing the API or have the wrong expectations.

This is happening by using a different sqlite3 database pointers, one
for each thread.

Cheers,

Shawn Wilsher
Mozilla Developer
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users