> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On > Behalf Of Hick Gunter
> Sharing a connection between threads makes it practically impossible for any > one thread to tell when a transaction begins or ends. From the point of view > of the database connection, the first statement to begin processing opens a > transaction and the last statement to end processing (which could be in a > totally different thread) closes it. IT ia all too easy to have a thread open > a > transaction and forget about it later. This causes all the other threads to > see > consistent (not stale) data. Enabling "read uncommitted" may alleviate the > sypmtoms, but it does not remove the cause. Seems like if we are going to share a single connection we would need to ensure that only one operation is happening at one time. I'm hoping that when you say above "and the last statement to end processing...closes it" means that if we guarantee to have just one set of prepare/step/finalize happening at one time on a connection then the next set will always start a new transaction. Does that sound correct? > Your assertions "a deleted row on one connection is found by a select on the > other" and "BEGIN/DELETE/COMMIT and SELECT is happening in the same > thread" is perfectly consistent if BEGIN/DELETE/COMMIT happens on one > connection and SELECT on the other. Yes that is exactly what we were doing. BEGIN/DELETE/COMMIT happened on one connection and SELECT on the other. Ooops. > As already stated, and per my own experience, each thread should have it's > own connection and do whatever it needs to do there, without interference > from other threads. I appreciate this point. Early prototyping indicated that this might not be possible for our system, which makes me a little nervous if that is what most users end up doing. We will definitely take another look at not sharing connections. Danke sehr Alex _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
