On 4/06/2009 12:57 PM, Nikolaus Rath wrote: > John Machin <sjmac...@lexicon.net> writes: >> On 4/06/2009 8:22 AM, Nikolaus Rath wrote: >>> Nuno Lucas <ntlu...@gmail.com> writes: >>>> On Wed, Jun 3, 2009 at 2:41 AM, Nikolaus Rath <nikol...@rath.org> wrote: >>>>> Nuno Lucas <ntlu...@gmail.com> writes: >>>>>> On Tue, May 26, 2009 at 5:17 PM, Nikolaus Rath <nikol...@rath.org> wrote: >>>>>>> Hello, >>>>>>> >>>>>>> How can I determine the rowid of the last insert if I am accessing the >>>>>>> db from different threads? If I understand correctly, >>>>>>> last_insert_rowid() won't work reliably in this case. >>>>>> It should work if you do: >>>>>> >>>>>> BEGIN >>>>>> INSERT ... >>>>>> last_insert_rowid() >>>>>> END >>>>> That would be very nice. But does "it should work" mean that you know >>>>> that it works (and it is documented and guaranteed)? The above sounds a >>>>> bit uncertain to me... >> Guaranteed? You're expecting a lot. Most software that you pay large >> sums of money for guarantee not much more than that the version numbers >> will be monotonically increasing. > > I trust you know what I mean. Guaranteed in the sense that the > developers try to make sqlite behave in this way and in contrast to "it > just happens to work right now, but it might change anytime without > warning".
"guarantee X" means "try to ensure X"?? You trust that I know that you mean that???? > >>>> It just means I'm too old to assume anything is certain. The Universe >>>> is always conspiring against you ;-) >>>> >>>> What I mean is that if it doesn't work, then you found a bug, most >>>> probably in your own code. >>> Well, now you are in direct contradiction to Igor who says that it does >>> not work: >>> >>> ,---- >>> | >> If all threads share the same connection, it is your responsibility >>> | >> to make "insert then retrieve last rowid" an atomic operation, using >>> | >> thread synchronization mechanism of your choice. Just as with any >>> | >> access to shared data. >>> | > >>> | > Is BEGIN ... COMMIT sufficient for that? >>> | >>> | No. Transaction is also maintained per connection. Starting a >>> | transaction would prevent other connections from making concurrent >>> | changes, but wouldn't block other threads using the same connection. >>> `---- >>> >>> >>> Any third opinions or references to documentation? >> <opinion> >> I don't see Igor saying it doesn't work. He says that it is not >> sufficient; *YOU* must maintain atomicity, using mutexes or whatever -- >> just as you need to "with any access to shared data" if you have >> multiple threads per connection. >> >> "if it doesn't work, then you found a bug, most probably in your own >> code" is not "in direct contradiction to Igor" ... I'd call it >> corroborative of Igor. >> </opinion> > > 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)". > Where am I wrong? In wasting time on semantic confusion instead of implementing it and testing the bejaysus out of it. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
