I don't know very well web2py internals (in the book at chapter 04 seems to behave like "all operations inside a function are executed inside a transaction, if an exception raises all opened transaction are rollbacked"). If it is like explained in web2py book this is the right "way" to do "normal" transactions in a stateless world (like the web one). In this default behaviour, if Alice hasn't "finished" the function and Bob "starts" the same function, sure there will happen race conditions (Bob istantiate a transaction while Alice's one is not committed yet)
chapter/06#commit-and-rollback gives you a hint... If you need to avoid the behaviour you explained, you need a different table design, but for the sake of discussion.....: before showing "you booked resource X", wouldn't db.commit() and re-selecting the record watching again the "occupied" value solve the problem ? On 1 Giu, 07:40, Mathew Grabau <grabau....@gmail.com> wrote: > Yes - that is exactly the problem that transactions are intended to > take care of. > > What would writing raw SQL do? Raw SQL statements (unless explicitly > contained in a transaction) would be executed outside of the > transaction and therefore still vulnerable. > > On May 31, 6:57 pm, David J <da...@styleflare.com> wrote: > > > > > > > > > I am confused. Isn't this exactly what transactions are for? > > On May 31, 2011 7:54 PM, "pbreit" <pbreitenb...@gmail.com> wrote: > > > > We aren't talking about a bank account (and even if we were, that's why > > > banks rely on reconciliation procedures), we are talking about a booking > > > system. It's like security, you're never 100%, just as close to 100% as > > you > > > need to be.
