In a threaded environment the simple and effective solution is to
synchronize your transactions with a mutex. You lose a little possible
concurrency but if you do not need it you simplify the logic no end and
have a more robust application.
Using pthreads you can improve a little by using read and write locks, a
sophistication on a simple mutex.
Richard Klein wrote:
Requiring the second transaction to complete first is expected in
terms of SQLIte's concurrency system.
So in terms of using SQLite, I need to close the entire transaction
and restart it when I get a "database locked" return code in a writer
thread? It's not enough to just retry the commit in a little while?
You don't need to close the connection, but you do need to ROLLBACK
the transaction, unless you have some sort of a priori knowledge that
the second transaction will not try to write to the database. In such
a case, the second transaction will not try to acquire the RESERVED lock
already held by the first transaction, and so the second transaction
will eventually run to completion. In such a scenario, the first
transaction can sit in a busy wait loop (sleep for a bit, then retry
the COMMIT) until the COMMIT succeeds.
However, if the second transaction will (or might) try to write to the
database, you must ROLLBACK the first transaction, sleep for a bit, and
restart the first transaction.
- Richard Klein
------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
