On 3 Feb 2014, at 6:07pm, Baruch Burstein <bmburst...@gmail.com> wrote:
> I am a little unclear on some of the ways transactions affect multiple > connections. I am assuming that multiple sqlite3 objects in one program is > the same as multiple programs. Wanted to check whether you'd read this, even though I have trouble understanding it myself: <http://www.sqlite.org/isolation.html> > 1) How does a transaction affect SELECTs? If I start a transaction and do > an UPDATE/DELETE/INSERT, what data will a SELECT in the same transaction > see? You can change it ... <http://www.sqlite.org/pragma.html#pragma_read_uncommitted> ... but you probably shouldn't. It's normal to consider a transaction-in-progress as a transaction that you haven't decided to do yet. In other words, it's the COMMIT that does everything important. Until that you're just making notes on the back of an old envelope. > What about a SELECT in a different connection? Generally speaking, either the database will have already been locked (in which case the SELECT will be delayed until unlock), or the SELECT will see the version of the database before changes. > 2) Can 2 connections run 'BEGIN;' ? If so, who gets the final say on the > data? Whichever COMMIT gets processed last. But it's your job as a programmer to use SELECT /inside/ your transaction to make sure there is never any argument. > The first to do the 'COMMIT;'? What will happen when the other does a > COMMIT? Check out the differences between BEGIN DEFERRED, BEGIN IMMEDIATE, and BEGIN EXCLUSIVE: <http://www.sqlite.org/lang_transaction.html> The default is DEFERRED. The simpler and safer way to think about it is to imagine everything does BEGIN IMMEDIATE. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
