Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Warlock : DSTM via Websockets

Warlock : DSTM via Websockets

Eric Schoffstall

February 23, 2013
Tweet

More Decks by Eric Schoffstall

Other Decks in Programming

Transcript

  1. 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
  2. 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
  3. DSTM • D stands for Distributed • DSTM will keep

    all clients in sync and notify clients of transactions
  4. 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
  5. 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
  6. Server Warlock = require "warlock" server = http.createServer().listen 8080 lock

    = Warlock.createServer server: server lock.add planet: name: "Mars"
  7. 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
  8. 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
  9. Middleware • Connect style middleware can be added for access

    control on any/all keys + pattern matching on keys
  10. 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
  11. 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)