[Catalyst] Dispatching with Chained vs HTTP method

Toby Corkindale tjc at wintrmute.net
Wed May 7 09:13:28 BST 2008


On Wed, May 07, 2008 at 09:55:10AM +0200, Zbigniew Lukasiak wrote:
> On Wed, May 7, 2008 at 7:57 AM, Toby Corkindale <tjc at wintrmute.net> wrote:
[snip]
> >  I wonder how one goes about implementing such a transaction on the server
> >  side.. One would not want to lock DB rows indefinitely, waiting for the
> >  client to finally complete the transaction. But if one just recorded the
> >  queries and then executed them all (internally) at the end, then other
> >  risks exist, eg:
> >
> >  $id = POST transaction
> >  $amount = GET /user/1/account_balance
> >  $amount2 = GET /user/2/account_balance
> >  PUT /user/1/account_balance/$amount-1
> >  PUT /user/2/account_balance/$amount+1
> >  PUT transaction/$id?completed
> 
> How about:
> 
> $id = POST transaction
> PUT /transaction/$id/payer/1
> PUT /transaction/$id/receiver/2
> PUT /transaction/$id/amount/1
> PUT /transaction/$id?completed
> 
> or even
> 
> $id = POST transaction
> PUT /transaction/$id?payer=1;receiver=2;amount=1
> PUT /transaction/$id?completed

There are other ways of doing it that would avoid the problem, but I'm just
trying to demonstrate potential flaws in any transaction that does not do
locking to prevent other things accessing it at the same time.
Perhaps I should try another example if the other wasn't clear.

Given this series of calls:
<transaction>
1) get value of item
2) get users bank balance
if balance > item-value, then:
3) subtract value from bank balance
4) assign item to user
</transaction>

What if the internet connection died for 30 seconds between step (2) and (4),
and in that 30 seconds, the user bought something elsewhere, thus reducing his
or her balance to below the value?

That's the sort of race condition that real databases can avoid, because
they'll basically stop anyone else modifying the balance after you've checked
it, until you commit or rollback the transaction.
We could do that too..
But imagine if we locked the user's DB row at step (2).. but then imagine if
the internet connection to the person who started the transaction died.. for
hours.. and during that time no other transactions could be made!
That's not so good either.

Toby



More information about the Catalyst mailing list