On Sat, Jun 23, 2012 at 1:24 PM, Anthony <abasta...@gmail.com> wrote: > No, when autocommit is disabled, that doesn't immediately result in a shared > lock being acquired and held indefinitely. A shared lock is acquired when a > select is made, but only held as long as it takes to actually do the reading > for that select. Just do a commit after your inserts/updates/deletes, and > you should be fine.
I don't think you are understanding, I'm not concerned about the case when the query/select finds work to do, I'm concerned about the case when the server looks, and finds nothing. I agree, when autocommit is on, the lock will be dropped after the query returns. However, it autocommit is off, and again referring to http://www.sqlite.org/lockingv3.html section 7: "After a BEGIN command, a SHARED lock will be acquired when the first SELECT statement is executed. ... The SQL command "COMMIT" does not actually commit the changes to disk. It just turns autocommit back on." Again, with autocommit off: The server process does a query/select to see if there is any work to do. This provokes SQLite to acquire a SHARED lock. Then the server process decides "oops, no work to do, let's go to sleep for a minute". Notice that it does nothing to release that lock. So the Web2py process is now locked out of doing any updates because the SHARED lock will block the acquisition of locks needed to actually write/update the database. I didn't find anything in the SQLite documentation that would indicate otherwise, but if you do, please point me to the specific document/section. (I just searched through The Book again and found no mention of autocommit. Searching for just 'commit' finds only a handful of places that make no mention of it either.) >> Since the documentation about what the DAL uses/needs/assumes about >> the underlying Python layer (pysqlite in this case) isn't there, its >> just easier to avoid using it outside of a Web2py application. > > > Seems rather extreme. What information do you need that would impact your > usage? Note, the good thing about open source is that you can just look at > the source code. Technically True. And that has allowed me to do my own work arounds (and submit patches), which has been extremely helpful. So for fixing bugs, it's great! However... One of the things I really like about Web2py is the promise of backwards compatibility. Is that promise meant to encompass all the current decisions embodied in the implementation? I wouldn't assume so. The Book does not say: "For anything not covered here, read the source and base your expectation of backwards compatibility on that." The Book does say: "web2py has always been built from the user perspective and is constantly optimized internally to become faster and leaner, whilst always maintaining backward compatibility." and "The source code of the Database Abstraction Layer was completely rewritten in 2010. While it stays backward compatible, the rewrite made it more modular and easier to extend." So I should fully expect the implementation to change; anything I find by "reading the source" is clearly something that is, and has been, subject to change. Sorry, but the only sane thing to do is to rely only on what is documented and covered under the blanket promise of backwards compatibility. -=D --
