if you're familiar with database transactions, web2py istantiate a new transaction every request and commit (if no exceptions are thrown automatically) at the end of the request.
in a module, if you want to roll your own "daemon", a transaction is initiated at the start of the script. You have to manually commit to "save" those changes. Issuing db.commit() every loop assures you that the db is consistent with what your daemon has processed already. The "blocking" part is referenced to databases like SQLite, that remain "blocked" if someone writes to the database and the commit is called later, i.e. - you have a queue of 500 messages - you start to send emails, updating or removing row by row to mark that email as sent - you commit at the end of the 500 block. While the email are being sent, SQLite will not allow others processes to read/write to that db, so if the "normal" web-application is in the need of reading/writing to the db, your daemon will block your application. With other db's this should not happen: if you update row by row with your daemon and don't commit those changes "line by line", your app will continue to work. The only caveat is that if some other process (another daemon or the app itself) reads from the table you're using to process email, until your daemon does not commit all the changes it made, those changes won't be "seend" by others. To sum things up, db.commit() ensures that all processes looking into that table "see" the same thing. The book advises against cron execution because if you schedule this daemon to start , let's say, every minute, it could be possible that: - on 00:00 your daemon starts processing the queue - on 00:01 another instance of your daemon starts processing the same queue if the first daemon is still processing the queue, you'll have two processes running for the same task, and if you don't prepare things for multiple "workers", things can get ugly (e.g. two identical emails sent - one from the first process, the second from the second)
