John Machin <sjmac...@lexicon.net> writes: > On 6/06/2009 8:19 AM, Nikolaus Rath wrote: >> John Machin <sjmac...@lexicon.net> writes: >>>> Now I'm confused. I want to know if it will be sufficient to wrap my >>>> last_insert_rowid() call between BEGIN .. and END in order to make it >>>> return the rowid that was last inserted by the same thread even if >>>> multiple threads are using the same connection (but different cursors). >>>> >>>> As I understand Nuno, he is saying that this is sufficient. Igor OTOH is >>>> saying that it's not sufficient, I need to use additional mechanism. >>> As Igor pointed out, if you have multiple threads using the same >>> connection, you ALREADY need mutexes or whatever to maintain atomicity. >>> If you don't have that, yes you need to "use additional mechanism" BUT >>> this constitutes an EXISTING bug in your code. Perhaps Nuno should have >>> added a rider like "(presuming your existing code is not stuffed)". >> >> Are you saying that I need to use mutexes or whatever in the following >> program? >> >> def thread1(): >> cur = conn.cursor() >> for i in range(500): >> cur.execute("INSERT INTO tab1 (no) VALUES(?)", i) >> >> def thread2(): >> cur = conn.cursor() >> for i in range(500): >> cur.execute("INSERT INTO tab2 (no) VALUES(?)", i) >> >> threading.Thread(target=thread1).start() >> threading.Thread(target=thread2).start() > > Somebody needs to use mutexes somewhere. You have obscured the question > by introducing two unknowns: (1) Which Python wrapper are you using > (sqlite3 module or the apsw module)? (2) What does it do under the > covers? Try asking the relevant guru for whatever you are using.
It's made for apsw and it shouldn't do anything under the hood. Consider the same example in C if it helps. >>>> Where am I wrong? >>> In wasting time on semantic confusion instead of implementing it and >>> testing the bejaysus out of it. >> >> When you are working with a multithreaded program, you can't even hope >> to test a fraction of the possible state trajectories. Finding the >> proper implementation by trial & error is therefore even more hopeless >> than in a single threaded program. > > If you can't test it, then how will you know whether *any* > implementation is "proper", let alone *the* "proper" one? Of course you have to test once you have defined proper behavior. But my question in this thread is essentially what the "proper" behavior is. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users