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.

Reply via email to