Though the example of $ is very intuitive, I am not suggesting that we drop one of the transaction and block the database forever (as it is happening now). Instead, it could be serialized such that two $100 transactions are committed to the db.
On Fri, Feb 10, 2012 at 10:33 PM, Igor Tandetnik <itandet...@mvps.org>wrote: > On 2/10/2012 9:57 AM, Sreekumar TP wrote: > >> The last transaction should always be the final one. In a a >> multiprocess/threaded application how can one make assumptions on the >> order >> of updates? >> > > There are two updates in my example: > > > update t set count = count + 1; > update t set count = count + 10; > > Do you feel it unreasonable to assume that, after these two statements are > executed successfully, in any order, the value of count should increase by > 11? > > If two $100 deposits to your bank account are made by different parties at > approximately the same time, I think you'd be pretty upset if the account > balance didn't increase by precisely $200. > > -- > Igor Tandetnik > > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
