On Wed, Jun 27, 2012 at 11:53 AM, Anthony <abasta...@gmail.com> wrote: >> > Yes, it does release the lock, as soon as the select is complete. You do >> > not >> > have to do db.commit() after a select. >> Please show me where that is documented. >> Section 7 of http://www.sqlite.org/lockingv3.html says that ONLY >> happens when autocommit is on, and you have stated that it is off >> (contrary to my mistaken memory). > > > End of Section 4: > > Once all reading has completed, the SHARED lock is dropped.
Thanks, I had missed that part. >> Further, The Book says that only >> inside of a Web2py app does commit/rollback back happen automatically. > > > Commit is not needed for a select. Committing is for committing changes to > the database -- selects only read from the database. Ok, so if (and I'm looking for a more general that just SQLite answer here), I want to get exclusive access to the DB, I should first do a 'dummy' change. More explicitly, if the server process were first to 'update' a record (solely for the purpose of locking the DB), then read through pending entries, it could mark them as 'working on by server process x', commit, and be sure that no other process (such as another worker/server or even a user coming in through web2py proper) would be able to also pick up that work? Even if that just works for SQLite, I'm cool, but I'd like a solution that worked for all DBs if that is possible without a lot of machinations. In slightly more detail, there could be a server's table, and as each server 'wakes up' looking for work to do, it could udpate its own row in that table (hence provoking a lock), look for work, flag the work as being handled by itself, then commit. It could then take its own sweet time to do the work, knowing that no other server process would have also claimed that work? -=Doug
