Hi Dennis,
I have just done some work on this. Take a look at this wiki page
http://www.sqlite.org/cvstrac/wiki?p=MultiThreading
The lock is only help while updating. If you follow the instructions in the above page
Updates in transactions
and you add a loop like the one in the solution then actual SQLITE_BUSY situation
should be reduced to a bare minimum.
You approach of using a secondary table to write to and see is not the best approach
because if the write works there is no guarantee that the write to your primary table
will work (someone might get in and still lock it)
Yet an update in a transaction if fails will rollback. So the code could look
something like
begin transaction
while not sqlite_busy and retries count not reached
update table
increase a retries counter
if sqlite_busy delay for some time (10ms)
loop
if not sqlite_busy then commit transaction else rollback transaction
regards
Greg O
----- Original Message -----
From: Dennis Volodomanov
To: [EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 11:07 AM
Subject: [sqlite] Checking the busy state
Hello,
I would like to check for the state of the database before letting the user change
any values, because it's on a LAN and could be in use by another machine, but how can
I do that without issuing a sqlite_exec() that would attempt to write something and
then checking for the SQLITE_BUSY? Is there any way except that?
If I understand correctly, I can set up a one-row table for that purpose and before
each modification try to write to it and see what the return is? But will I get a
SQLITE_BUSY if another table is being used? Does SQLite lock the entire database when
it works with it or just one table? I read the explanation of SQLITE_LOCKED, but it
didn't answer my question - as I understood it, it means if I screw up somehow then
it's issued?
Thank you in advance,
Dennis
