I would endorse that. It makes the logic simpler and execution more
efficient compared with the various polling strategies used to look at
file locks. It is particularly the case if you multi-use is due to
threading in a single process.
Ritesh Kapoor wrote:
I think a good way of using sqlite in a multithreaded app is to have
your own mutex lock for the DB.
Everytime you need to execute a query just call the lock() function for
your mutex and then proceed with sqlite3_exec() calls. Followed by a
unlock() call.
Your mutex wouldn't return if the another thread is executing queries.
The only thing you need to do is to remember to lock and then unlock the
mutex. You could again put all this in a function and call that
function whenever you need to execute a query.
However if you really insist on using the busy handlers then I guess
someone on this mailing list would help you. However my experience with
these handlers was that they made a mess of the code and later on the
code was incomprehensible to someone looking at the code for the first
time.
------------------------------------------------------------------------
Subject:
[sqlite] implementing busy_handler callback
From:
[EMAIL PROTECTED]
Date:
Wed, 23 Aug 2006 10:17:58 +0530
To:
sqlite-users@sqlite.org
To:
sqlite-users@sqlite.org
CC:
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Hi All,
I am trying to integrate SQLite in a multithreaded C++ application which
runs on Linux. I have gone through the SQLIte documentation, but it's not
clear whether the sqlite3_exec() will retry the query when the busy
handler callback is implemented and returns a non-zero value.
From the sqlite3_busy_handler(sqlite3*, int(*)(void*,int), void*)
definition it says "This routine identifies a callback function that might
be invoked whenever an attempt is made to open a database table that
another thread or process has locked. If the busy callback is NULL, then
SQLITE_BUSY is returned immediately upon encountering the lock. If the
busy callback is not NULL, then the callback will be invoked with two
arguments. The second argument is the number of prior calls to the busy
callback for the same lock. If the busy callback returns 0, then no
additional attempts are made to access the database and SQLITE_BUSY is
returned. If the callback returns non-zero, then another attempt is made
to open the database for reading and the cycle repeats.
Does it mean the sqlite3_exec() internally takes care of invoking the
query multiple times until the callback returns 0? Can someone provide
sample implementation for busy_handler callback and how the query is
retried?
thanks,
Vadivel
*********************** FSS- Confidential ***********************
*********************** FSS- Confidential ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software Systems (FSS) and is intended solely for the use of
the individual to whom it is addressed. It may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this email including damage from virus."
------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
