> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On > Behalf Of Igor Tandetnik
> Realize that a transaction is a property of a connection, not a thread or a > query. Suppose thread A starts a read at time T and ends it at time > T+20; and thread B starts a read on the same connection at time T+10 and > ends it at T+30. Both reads are part of the same unbroken transaction lasting > (at least) from T to T+30. If there's an update committed at T+5 on a > different > connection, neither read would see it, even though thread B started after it. Gnash, yup this does sound like our problem. We have unfettered access to the read connection by any thread without a lock. Our failure cases seem to always look like: a) Thread 1 executes a SELECT on connection A but gets swapped out after the sqlite3_step b) Thread 2 executes a DELETE on connection B, this completes c) Thread 2 executes a SELECT on connection A this completes but sees the deleted row still there d) Thread 1 completes SELECT from a) on connection A Looks like we will need to lock access to the read connection. In my original post I said we had done that and it didn’t help, but we just locked the step, not the prepare/step/finalize so I'm guessing if we lock all three we will be ok. Just to clarify, when you talked about 'starting' and 'ending' a read can I take that to mean the time between sqlite3_prepare and sqlite3_finalize? Thanks for the info Alex _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
