Feral Concurrency

Kevin Burke

@derivativeburke

Who is this talk for?

What happens when you
create a user in Rails?

Four queries!

This is slow

This is incorrect!

You can get duplicate records

Two records with the same email

Bad consequences

Feral Concurrency: the paper

Paper abstract

BEGIN/SELECT/INSERT/COMMIT is not safe at READ COMMITTED

more info

Most databases default to READ COMMITTED

Some Rails functions *skip* the validations

Rails functions that skip validations

Surprise: the correct way is also faster

Demo

Why do ORM authors prefer the slow way?

Requires O(N) error handling

Works with all databases

Another bad ORM pattern

Read-check-update-save

Vulnerable to races!

Read-check-update-save

Our #1 cause of oncall incidents

One query

Don't use save()

Back to the paper

Paper Results

Example transaction use (Spree)

No transactions used

Chesterton's Fence gone wrong

I think we should get rid of the [optimistic lock] since there's no documentation about why it's there...

Conclusion

Conclusion (1)

DATABASE EXPERTS: (do
30 years of research on
consistency and locking)

RAILS: Nah, we're good

Lesson: cross-DB flexibility is extremely valuable

Opportunity: common interfaces for error handling, CRUD

Make it easier for ORM developers to use your database

Unique constraint failure

Learn to evaluate ORM's

Use ORM's better

burke.services

Thanks!

Kevin Burke

kev.inburke.com

kev@inburke.com

@derivativeburke


These slides are available at:

kev.inburke.com/slides/feral-concurrency

/

#