SQLite is a file-based database, so has to have more course locking than a typical client/server database. Other databases have "select for update" functionality, which allows you to select a set of records and lock them. web2py actually supports this, via .select(..., for_update=True).
Anyway, you might be better off looking into using the scheduler<http://web2py.com/books/default/chapter/29/4#Scheduler-(experimental)>, or a third-party task queue like Celery <http://celeryproject.org/> (a web2py Celery plugin <http://code.google.com/p/web2py-celery/> was started at some point, though not sure it is complete). Anthony > 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 >
