I'm looking to potentially use background task(s) to offload sending
of emails and updating of other offline resources, and I'm trying to
sort out what the implications are.

In the PDF of the book (just released for free, thank you!), page 389,
section 8.5 "Sending messages using a background task" is the
following text:
"Also notice that it is important to commit any change as soon as
possible in order not to lock the database to other concurrent
processes.
As noted in Chapter 4, this type of background process should not be
executed via cron (except perhaps for cron @reboot) because you need
to be sure that no more than one instance is running at the same
time."

So I'm puzzled, if the database is locked, then shouldn't multiple
accessors should be fine?

The email task example, spanning pages 388-389, does a db.commit()
every in body of a loop that is processing the rows rather than at the
end of the loop.
What/where are the locks obtained in this sample script?
Since the script never exits, it can't be just running the script?
Is the lock obtained on the update call and then released on the
commit? I'm not having much luck figuring out how to avoid locking
issues when I can't seem to figure out when Web2py takes and releases
locks. I've just re-read chapter 6 and am still puzzled. Pointers to
where else to look are appreciated.

Thanks
   -Doug

Reply via email to