So it has nothing to do with which table/row the transaction is modifying? In your example connection 2 always returns with an error on COMMIT?
Seems like the improvement is only on when the error occurs and not on concurrency or am I missing something? -- Marco Bambini http://www.sqlabs.com http://twitter.com/sqlabs > On 26 Mar 2018, at 09:41, Simon Slavin <slav...@bigfraud.org> wrote: > > On 26 Mar 2018, at 8:09am, Marco Bambini <ma...@sqlabs.net> wrote: > >> Is there a better formal description about the "transactions may not >> overlap" sentence? >> Is there any example about overlapping transactions? > > Overlapping transactions occur when a second connection does a BEGIN before > the first connection does its COMMIT. It's difficult to present it well > without colours or fixed-width fonts, but try this: > > connection 1: BEGIN CONCURRENT > connection 1: -- various database reads and updates > connection 2: BEGIN CONCURRENT > connection 2: -- various database reads and updates > connection 1: COMMIT > connection 2: COMMIT > > (Alternatively the COMMIT lines could occur in the other order. Either way, > the transactions are overlapping.) > > Using normal BEGIN variants, the thread executing the third or fourth lines > would be the one which noticed the problem. The thread would be delayed and > may eventually return SQLITE_. This new variant BEGIN CONCURRENT ensures that > the thread executing the second BEGIN is not delayed, and that instead the > error is returned when that connection executes the COMMIT. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
