Warlock : DSTM via Websockets

Transcript

1. Warlock DSTM via WebSockets
2. 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
3. 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
4. DSTM • D stands for Distributed • DSTM will keep all clients in sync and notify clients of transactions
5. 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
6. 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
7. Server Warlock = require "warlock" server = http.createServer().listen 8080 lock = Warlock.createServer server: server lock.add planet: name: "Mars"
8. 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
9. 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
10. Middleware • Connect style middleware can be added for access control on any/all keys + pattern matching on keys
11. 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
12. 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)