I found that although sqlite claims thread safeness it is actually in your
hands to implement a thread safe access pattern.
Here is how I implemented my sqlite thread saftey. Each thread opens its on
connection.
All operations begin with a
do {
BEGIN EXCLUSIVE
if (isbusy) (sleep some amount of time... ).
} while (sqlite isbusy);
YOUR SQL STATEMENTS HERE.
And end with a
COMMIT;
The begin forces sqlite to lock the DB for exclusive access. This makes
the remaining access error handling relatively simple. No need to check for
busy and do rollbacks with restarting logic... Just handle errors, in my log
the error to a file and returns a Failure code which typically causes the
application to exit.
Don't to forget to compile the sqlite library with -DTHREAD_SAFE
Rafi Cohen <[EMAIL PROTECTED]> wrote: Hi, I read the good article on this
subject and also the api refference
in the documentation and still feel that I need to ask the following
question.
My application has 2 threads. The main one needs to retrieve data thru
select commands but does not change the database, while the other thread
will change the database quite often.
My questions are: should I open the database in each thread separately
or can I open it once for the whole program? in the second case, does it
matter inh which thread I open it? last, if the main thread happens to
retrieve data while the other thread is in a transaction changing the
database, I would prefer the main thread wait till the end of the
transaction and retrieve the most updated data. How do you suggest to
implement it?
looping on sqlite3_busy_handler should be the way to go?
Thanks, Rafi.
