11 Jan 2013 sness   » (Journeyer)

How our users exploited concurrency and how we fixed it - Evil Trout's Blog

How our users exploited concurrency and how we fixed it - Evil Trout's Blog: "Fortunately, I soon found an easy solution: let the database handle the concurrency. Much smarter developers than me have put in thousands of hours of work into databases to make sure they hold up under concurrent situations such as these. All I’d have to do is leverage their hard work.

Here’s the solution I came up with:

Player.transaction do

# Update completed attribute to true, but only when it's currently false
row_count = Goal.update_all "completed = true", ["player_id = ? AND completed = false", player.id]

# update the player score only if completed changed in the database
if row_count == 1
player.increment!(:score, goal.score)

The key to the above solution is that your RDBMS will return a count of how many rows it changes when you execute an UPDATE. Only one request will receive a row count of 1 back. All others will receive 0 and will execute nothing. It just works!


'via Blog this'

Syndicated 2013-01-11 18:21:00 from sness

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!