Warlock DSTM via WebSockets 

STM • Stands for Software Transactional Memory • Alternative to locking for concurrency control • Every read/write happens within a transaction • Extremely useful for sensitive data where conflicts are bad (financial transactions) • Good strategy for resolving conflicts 

Transaction • Any changes to the shared object must be made in a transaction • Each transaction maintains a changelog that can be reverted • If a transaction is conflicting it will be restarted • A transaction can never be completed while data is out of sync 

DSTM • D stands for Distributed • DSTM will keep all clients in sync and notify clients of transactions 

STM vs. Locking • Instead of locking the object STM allows concurrent transactions to complete as long as they don’t conflict • STM is proven to be faster than locking for concurrent transactions 

Warlock • Warlock is a STM implementation in node.js • You have a Warlock server that contains the main object and clients can submit transactions to it • Warlock keeps all connected clients in sync 

Server Warlock = require "warlock" server = http.createServer().listen 8080 lock = Warlock.createServer server: server lock.add planet: name: "Mars" 

Client lock = Warlock.createClient() addMarsSize = lock.atomic -> planetName = @get "planet.name" if planetName is "Mars" @set "planet.equator.size", 3396 @done() else #Wait until another transaction happens then try again @retry() addMarsSize.run (err) -> # err will exist if the transaction was aborted 

Data binding • Since warlock keeps all clients in sync you can bind the root object to the DOM • Pass lock.root into any binding library • For two-way transactions use transactions to push changes • Rivets examples available 

Middleware • Connect style middleware can be added for access control on any/all keys + pattern matching on keys 

Comparisons • Racer – Doesn’t support STM, tied to derby, big code base, best library available for syncing simple models but no transactions • AtomizeJS – Not written to scale, massive code base, messy • Meteor – Not written to scale (uses database polling WTF), security problems 

Summary • Use DerbyJS instead of Meteor if you want to scale past 10 users • Use Warlock if you want to scale past that (plus real syncing/transactions)