Hi,
Actually, you're better off setting a timeout rather than handling
retry in your own code:
<https://sqlite.org/c3ref/busy_timeout.html>
As I understand it, SQLITE_BUSY can occur in two situations: one where
busy looping will fix it and one where it won't. Using the busy_timeout
handles the first case automatically and means that if you get
SQLITE_BUSY in user code it's always the deadlocking variant.
To get around those deadlocks you have to abort the whole transaction
and retry from the beginning. Keith explains some of these scenarios in
more detail in a message a few moments before your own so I won't repeat
them here.
Nevertheless, you need to retry because of concurrency contention, which
can be handled automatically and reasonably efficiently, *AND* you need
to retry at the business logic layer due to ACID correctness guarantees
being provided and enforced.
Transactions can also fail for other reasons (such as a UNIQUE
constraint violation or a read-modify-write hazard that happens when
another transaction changes some data that you read and are manipulating
and writing back) and you need to be able to recover from these
scenarios.
Having said that, SQLITE is nice because its single writer model means
that read-modify-write hazards are less of a problem than other RDBMSes,
provided transactions that intend to write use BEGIN IMMEDIATE.
--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
http://www.gonumber.com/andyjpb
0x7EBA75FF
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
