Hey everyone,
Thanks for your reply, Igor! I've got two more questions, now.
Is it also true that if a select statement executes (in any thread)
before #50 in my example below, it could return data that aren't
durable?
My second question is more complicated. How expensive is opening a
new connection? My inclination is to keep a pool of connections and
write logic so that each transaction has exclusive control of one
connection for the lifetime of that transaction. Are there
circumstances under which it'd be faster to just always open a new
connection?
Thanks so much for your help.
Cheers,
Don
On Nov 10, 2007, at 1:24 PM, Igor Tandetnik wrote:
Don Lavelle <[EMAIL PROTECTED]>
wrote:
Second, my question is about SQLite and multi-threading. Basically,
the snippet below means that if I have multiple threads executing SQL
statements, and I want at least one thread to execute multiple SQL
statements as a single unit, I need to make sure only one thread at a
time is executing SQL, or the SQL statements that are outside of the
thread may get lumped in with the transaction. As in,
10. thread 1: shut off auto commit
20. thread 1: SQL statement 1 succeeds
30. thread 2: independent SQL statement succeeds
40. thread 1: SQL statement 2 fails
50. thread 1: rollback, taking with it thread 2's effect
This is correct, assuming both threads are using the same database
connection. The behavior would be different if each thread opens
its own connection (specifically, the second connection could not
successfully commit a change at #30).
Igor Tandetnik
----------------------------------------------------------------------
-------
To unsubscribe, send email to [EMAIL PROTECTED]
----------------------------------------------------------------------
-------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
