# Embedding everything inside a transaction **URL:** \ **Category:** Rails\ **Created:** [August 3, 2008, 4:39am UTC](https://www.ruby-forum.com/t/embedding-everything-inside-a-transaction/144849 "2008-08-03T04:39:33Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![stefan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/bbce88/32.png) [@stefan](https://www.ruby-forum.com/u/stefan)\ **Post date:** [August 3, 2008, 4:39am UTC](https://www.ruby-forum.com/t/embedding-everything-inside-a-transaction/144849/1 "2008-08-03T04:39:33Z")
Hey Guys, 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 last. 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 UPDATE) … Doesnt work. Found out that FOR UPDATE only works inside a transaction. damn. - 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. Thanks!!! Stefan ---
**Author:** ![stefan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/bbce88/32.png) [@stefan](https://www.ruby-forum.com/u/stefan)\ **Post date:** [August 3, 2008, 1:12pm UTC](https://www.ruby-forum.com/t/embedding-everything-inside-a-transaction/144849/2 "2008-08-03T13:12:26Z")
On 3 Aug 2008, at 03:39, Stefan B. wrote: > some milliseconds. Enough to have some bad concurrent requests. For > get bought and the money column is saved from the thread that finishes > 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 an around\_filter could do that for you. > - any other ideas? Maybe someone faced a similar problem. I wrote up some approaches to similar problems here: [http://www.spacevatican.org/2008/6/8/dealing-with-concurrency](http://www.spacevatican.org/2008/6/8/dealing-with-concurrency) Fred ---
**Author:** ![stefan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/bbce88/32.png) [@stefan](https://www.ruby-forum.com/u/stefan)\ **Post date:** [August 3, 2008, 1:31pm UTC](https://www.ruby-forum.com/t/embedding-everything-inside-a-transaction/144849/3 "2008-08-03T13:31:54Z")
Frederick C. wrote: > On 3 Aug 2008, at 03:39, Stefan B. wrote: > > an around\_filter could do that for you. > > > - any other ideas? Maybe someone faced a similar problem. > > I wrote up some approaches to similar problems here: > [Dealing with concurrency - Space Vatican](http://www.spacevatican.org/2008/6/8/dealing-with-concurrency) > > Fred Thank you so much. That was very helpful! ---
**Author:** ![stefan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/bbce88/32.png) [@stefan](https://www.ruby-forum.com/u/stefan)\ **Post date:** [August 3, 2008, 1:43pm UTC](https://www.ruby-forum.com/t/embedding-everything-inside-a-transaction/144849/4 "2008-08-03T13:43:39Z")
Just figured that the approuch with the around\_filter could turn out really awsome as it is a solution for another topic i have. If you have user accounts and a support team, and want to have the support team able to log into the user accounts, but shouldnt be able to do any changes, this will come in very handy as well. You could raise an exception like “SupportTeamChangesNotAllowed” after the yield and everything would get rolled back. Even simple things like user.last\_logged\_in\_at would be touched. Just wanted to share the idea, think that can come in quite handy.