Can this situation be handled in sqlite - by upgrading the lock to a writer lock ? Since both applications use the same WAL file for read and writes, it shouldnt be a problem , because all changes will be in linear sequence ?
Sreekumar On Fri, Feb 10, 2012 at 10:49 PM, Sreekumar TP <sreekumar...@gmail.com>wrote: > 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
