I've searched the depths of the world wide web for a solution to my
problem with concurrent requests.
The problem is the following:
In my App I initialize the user in a before_filter, with a bunch of
included associations, processing cached columns yadda yadda. This takes
some milliseconds. Enough to have some bad concurrent requests. For
example (not a real scenario but describes the problem pretty well):
A user is logged in in two browser tabs and fires two request or more at
the same time. All requests are targetting the action "buy_the_item".
The action checks if the user.money column has enough money and if yes,
the item will be purchased. Now many requests are running in concurrent
threads, and all have the same value of user.money ... so all the items
get bought and the money column is saved from the thread that finishes
Ok how can I solve this? I'd like your opinions...
I had some Ideas:
- try loading the user in the filter with pessimistic locking (FOR
... Doesnt work. Found out that FOR UPDATE only works inside a
- starting a transaction inside the action and THEN reload everything i
need with FOR UPDATE
... that would generate so much (to much) overhead. cause half of the
requests deal with changing dependent table data.
- place the WHOLE request inside one single transaction and do
everything the normal way
... I'd like to try that... but how
- any other ideas? Maybe someone faced a similar problem.