SQLITE_BUSY is not an error...just a fact.
All your processes cannot work on the database at the same time...at least not
when one of them is doing an insert. You could be changing the table while
you're scanning it. EXXCLUSIVE doesn't change that idea.
Somebody please correct me if I'm wrong on this one...
I think sqlite can work with multiple processes just doing read-onliy
operations (like SELECT). It's just the write operations (INSERT/UPDATE)
which will cause SQLITE_BUSY to occur.
Michael D. Black
Senior Scientist
Northrop Grumman Mission Systems
________________________________
From: sqlite-users-boun...@sqlite.org on behalf of liubin liu
Sent: Tue 5/11/2010 9:20 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] multi processes, so many errores of SQLITE_BUSY and
SQLITE_MISUSE
Thank you very much!
It may be because my system's resource is limited. It's a embedded system
containing 32M RAM, ARM9 CPU.
My "reiterating 20 times" is already using usleep().
After I add the loop in the prepare statements, the system performance is
still very bad... And there are still many errores of SQLITE_BUSY.
The only improvement is the disappear of the error of SQLITE_MISUSE.
And I tried to use the "BEGIN EXCLUSIVE TRANSACTION". The things are same
with them without using it.
Black, Michael (IS) wrote:
>
> Your "reiterating 20 times" is not using a usleep so you'll blow by this
> most every time it's busy.
>
> Do this instead in all your proc's
>
> ret = sqlite3_step (p_stmt);
> if (SQLITE_BUSY == ret)
> {
> int n=0;
> usleep(100000); // try one more time before error
> while ((ret=sqlite3_step(p_stmt))==SQLITE_BUSY) {
> printf("proc1 ret==BUSY %d\n",++n);
> usleep(100000);
> }
> }
>
> And you'll also need to handle "database is locked" coming from your
> prepare statements. I saw that error too.
> You'll need to loop there too.
>
> The more you drop the usleep time the more times it will show as busy.
> 1/10th or 1/100th of second is about all you want I would think.
>
> And get rid of the usleep at the bottom of each proc -- it's pretty
> useless at 100 microseconds. You don't need to sleep unless you're busy.
>
> I tested your code with this and got no errors at all -- just a bunch of
> BUSY messages.
>
>
> Not sure what your purpose is in sqlrun.c with looping and killing. Looks
> pretty squirrely to me. You're not waiting for the forks to finish so
> what is your logic here?
>
> Michael D. Black
> Senior Scientist
> Northrop Grumman Mission Systems
>
>
> ________________________________
>
> From: sqlite-users-boun...@sqlite.org on behalf of liubin liu
> Sent: Tue 5/11/2010 4:57 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] multi processes, so many errores of SQLITE_BUSY and
> SQLITE_MISUSE
>
> ...
>
> --
> View this message in context:
> http://old.nabble.com/multi-processes%2C-so-many-errores-of-SQLITE_BUSY-and-SQLITE_MISUSE-tp28522127p28522127.html
> Sent from the SQLite mailing list archive at Nabble.com.
>
> _______________________________________________
> 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
>
>
--
View this message in context:
http://old.nabble.com/multi-processes%2C-so-many-errores-of-SQLITE_BUSY-and-SQLITE_MISUSE-tp28522127p28531394.html
Sent from the SQLite mailing list archive at Nabble.com.
_______________________________________________
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
