Richard Klein <[EMAIL PROTECTED]>
wrote:
John Firebaugh wrote:
I take it this mean that if, say, thread A begins a transaction, and
modifies the database, then thread B modifies the database, then
thread A commits the transactions, B's modifications are also
committed?
Nope. Once thread A begins a transaction, no other thread (or
process)
can modify the database until thread A commits. (That's what "atomic
transaction" means!)
Not true. Another thread in the same process can modify the database via
the same connection. The two just can't do that simultaneously.
In the above scenario, thread B will likely get a SQLITE_BUSY when he
tries to UPDATE. He should sleep for awhile and try again.
That would happen if thread B had its own, separate connection, but not
when the two threads are working with the same connection. As far as
SQLite is concerned, there's no difference between a single thread
making two changes to the database within a single transaction, or two
threads each making one change. Transaction control is per connection,
not per thread.
Igor Tandetnik
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
