Am 2012-07-10 20:50, schrieb [email protected]:
In http://ideone.com/eWPWD is my example code.
I would like to know if this would be an appropiate implemetation/use
of
BEGIN IMMEDIATE
and sqlite3_busy_timeout.
sqlite3_busy_timeout is specified once per db connection.
Probably at the beginning after sqlite_open
However, I think you slightly missinterpret the story about
SQLITE_BUSY:
First of all: Any sql operation that works on the DB might
return with an SQLITE_BUSY - No matter if its SELECT, INSERT, BEGIN,
COMMIT, etc.
It is in the hand of programmer to deal with that:
a) by some help from sqlite by using the busy timeout, which
internally causes sqlite to retry a statement until the timeout.
b) by manually retrying the operation that returns
the busy state.
Be aware that you may not only deal with SQLITE_BUSY but also
with SQLITE_LOCKED.
By surrounding you sql commands with an BEGIN IMMEDIATE you just
move the issue from the INSERT command one level up to the BEGIN
statement - the principal handling of SQLITE_BUSY remains untouched.
I think the tip to use BEGIN IMMEDIATE concerns the deadlock situation
rather than a simple busy handling: It is used to make sure that a
typical cursor operation on a table that might change data in
the DB doesn't dead lock because another process has a pending lock
acquired in parallel. But that's another story anyway...
Marcus
As I understood from the documentation and literature about
Transaction
and locks
the sqlite3_step is the action state part so I enclosed sqlite3_step
with BEGIN IMMEDIATE and COMMIT, but then occurred errors from the
sqlite3_prepare_v2
In http://www.mail-archive.com/[email protected]/msg17107.html
is explained why the sqlite3_prepare_v2
can cause a SQLITE_BUSY
So I enclosed now all db-concerning steps with BEGIN IMMEDIATE
and COMMIT.
With this construction appear still some database lock errors but
lesser
then with a
sqlite3_busy_timeout(db, 23) e.g.
As I understood, the BEGIN IMMEDIATE would try to get the RESERVED
lock
once, and if it fails it gets a SQLITE_BUSY.
The BEGIN IMMEDIATE will however try to get the RESERVED lock many
times
, if a sqlite3_busy_timeout is defined, but all tries happen within
the
time defined by the sqlite3_busy_timeout.
This behaviour is promoted here
http://www.mail-archive.com/[email protected]/msg10447.html
Or is it like this, that
BEGIN IMMEDIATE tries it again exactly once again after the timeout ?
In literature it is also mentioned that the BEGIN IMMEDIATE has to
be
resetted.
How and where do I have to do this in my example code ?
I would appreciate some suggestions
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
