Igor,
Thanks for your help. I've tested the first case successfully.
For a multi-threaded application using an in-memory database (":memory:"),
would you recommend:
a) an external mutex to synchronize exclusive access to the database --
probably the safest
b) an external read-write lock to allow concurrent reads but only one write
(parallel of SQLite locking as I understand it)
c) rely on SQLite locking and handle SQLITE_BUSY cases as described below
Both SELECTs and UPDATEs will be occurring from multiple threads approximately
10 times/second, and my original question below will be quite common (SELECT a
group of records and make UPDATEs as I step through them).
Larry
----- Original Message ----
Larry Lewis <lewislp-/[EMAIL PROTECTED]> wrote:
> If I am stepping through the results of a SELECT and want to UPDATE
> values in the currently selected row prior to completion of the
> SELECT query, will this work?
Yes, in the recent enough SQLite version.
> What if there is already a pending writer lock on the database from a
> different thread?
SQLite will detect the deadlock, and fail your UPDATE statement with
SQLITE_BUSY error. Your only option at this point would be to reset the
SELECT statement and finish the transaction this query was part of (if
any).
Igor Tandetnik
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
