On Sat, Jun 16, 2012 at 2:38 PM, Niphlod <niph...@gmail.com> wrote: > 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.
Yup, that part makes sense. And I assume it is true regardless of which DB engine(?) Which is why sending even one email in your controller is likely to cause a delay for other users of the site. > 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. Ok, so a transaction is opened when the script starts (actually, when DAL is called/created)? But here is where I get confused. First time through the loop, a record is updated and db.commit() is called. So far so good, the DB is committed and the transaction ends. Second time around the loop, a record is updated (???) and db.commit() is called. What transaction is that in? When did that transaction start and why isn't the web app talking to the same DB just as blocked by my daemon as it would be if I had done the loop in my controller? > 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. Yup, I get that you want to commit every loop and release a lock so that other processes can get access to the DB... > 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) Right. What I'm trying to find out is how to write a separate daemon that won't interfere with Web2py's access to the DB while it is running and I'm not yet getting a good mental model of how to structure the main loop (as per the example in The Book, on pages 388 and 389) as I cannot see there where transactions are started, just where they are commited. Thanks for trying to explain I hope I can come to an understanding but I'm not quite there yet! --=Doug
