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
On May 31, 10:29 pm, Vasile Ermicioi elff...@gmail.com wrote:
you can use record versioning to solve that somehow
http://web2py.com/book/default/chapter/07#Record-Versioning
Thanks for the feedback, but the info you provided is for archive, not
for dealing with parallel update. Or do I miss
I wouldn't worry too much about it. As long as you check for its
availability immediately before assigning it to a traveler, you'll be fine.
Then you'll need to run a periodic job to release pending reservations that
do not complete.
If you have a record version number field in the table then you can read it
for the record of interest. When you go to update the record you specify the
expected version number in the update equivalent to the SQL WHERE along with
the field id so if the version number has been incremented by
On May 31, 11:10 pm, pbreit pbreitenb...@gmail.com wrote:
I wouldn't worry too much about it. As long as you check for its
availability immediately before assigning it to a traveler, you'll be fine.
Then you'll need to run a periodic job to release pending reservations that
do not complete.
It's a theoretical problem, not an actual one. If you check room
availability before reserving the room, you'll be fine. If your service ever
gets enough traffic for it to become a problem (highly unlikely), you will
have the resources to address it. It's better to spend your energy trying to
This is not a theoretical but a very actual and serious problem.
Think about a bank account, you might be in a deadly embrace.
Web2py is not a only user that access database.
So the problem is not solved in web2py.
If i were you, i would write a raw sql statement.
On 6月1日, 午前1:25, pbreit
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.
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,
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
10 matches
Mail list logo
