You're forgetting another "layer". DAL leverages on DBAPI implementation of sql drivers. Actually, there is no "begin" transaction on python..... Usually you instantiate a cursor, do operations, try to commit, if exception is raised you rollback.
You can do all kind of tests for your background operations just defining a simple model and starting two separate web2py's shells (web2py.py -M -S youappname). One is representing the app (1), the other is representing the daemon (2). Remember that shell never commits unless told so (yeah, more control over it for your tests). I just tried and seems that I need to correct my previous statement: lock occupies the window of time between the db.commit() and the end of the call itself. Try yourself: - select table on 1, select table on 2 --> no problems - update one row on 1 (without committing), select on 2. no locking, 2 shows table as it was before the update on 1, so no problems - commit on 1, select on 2. No locking, 2 shows the table with updated records A little more complicated: get on an infinite loop inserting 10 rows, without committing. while the loop is running on 1, try a loop of 100 updates to those records, then commit. Occasionally you'll be presented with "Database is locked" error.