concurrency + Mongo Doug Woos engineer, gamechanger Monday, August 20, 12 

Concurrency • Multiple, interacting computations • Processes modifying same or dependent records • Relational: solved with transactions (2PC) • Mongo: no transactions (right?) • So, how do we do this? Monday, August 20, 12 

Examples • Multiple users scoring one game • One user, scoring on device, following on web • Background updates run on multiple nodes Monday, August 20, 12 

atomic updates • $set, $unset, $inc, $push, $pull, $addToSet . . . • $ operator, upserts . . . • findAndModify Monday, August 20, 12 

Atomic Updates • Don’t support all operations • Schema design important! • If we need to do a read first, can’t use Monday, August 20, 12 

Isolation Queue • Do all modifications in a queue processor • Only allow a record to be in the queue once • Compare to Java “synchronized” (monitor) Monday, August 20, 12 

Isolation Queue • Part of the Dockets library • github.com/gamechanger/dockets • Guarantees: • Updates will not conflict • Last update will be run • Intermediate updates may not be Monday, August 20, 12 

Isolation Queue • Requires a queue • Not everything can be async • Slower than Mongo atomic operators Monday, August 20, 12 

Optimistic Transactions • Like Redis, sort of • Don’t lock, but detect conflicts using save_date Monday, August 20, 12 

Monday, August 20, 12 

Optimistic Transactions • Single-record only • Slower than atomic updates • Inefficient when there’s a lot of contention Monday, August 20, 12 

Conclusions • Safe concurrency != ACID • Schema design is important • No one-size-fits-all solutions in NoSQL! Monday, August 20, 12