On Fri, Jan 2, 2015 at 3:25 PM, James K. Lowden <jklow...@schemamania.org> wrote:
> On Thu, 25 Dec 2014 05:32:45 -0700 (MST) > Rick Kelly <rpke...@gci.net> wrote: > > > All SELECT type requests are wrapped with BEGIN TRANSACTION/COMMIT > > That shouldn't be necessary and afaik isn't necessary. SELECT does not > modify the database. To "commit a select" is to apply the nonchanges. > > A common misconception is that BEGIN TRANSACTION "takes a lock" in some > sense. It doesn't; it marks a point in logical time that will be > concluded with COMMIT/ROLLBACK. Locks, if any, are implicit in the > SELECT itself. > I think the idea is at begin transaction (selects....) is that the transaction is left open so that state can continue to be queied while other transactions are also created and commited or rolled back at the same time (?) ... like using a monotone version control database and having a current 'head' which is what you get when you select... > > --jkl > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > 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
