Actor Model vs Master Worker Patterns for Concurrent

Actor Model vs Master Worker Patterns for Concurrent Reactive Process Design by Emanuele Gherardini (e. gherardini@yahoo. it)

Agenda Ø Who am I (aka disclaimer) Ø Why on the earth should we care about this stuff ? ! Ø The stuff…

Who am I == !(Who I am not) ! Martin Fowler ! Martin Odersky ! Kent Beck ! Robert Martin ! Joshua Bloch ! Brian Goetz

Who I am… Really ^_31 Years old Software Engineer Always a passionate and enthusiast student… DO NOT BELIEVE ME (try it!) 6 years of professional experience Working @ Ringmaster: System Architect of the GTech Gaming Platform

Why should I care? Cloudy reasons… http: //www. reactivemanifesto. org/ We (devs) now have great tools…

The question is… Do we know how to use them ? Probably not…

Super-Simple-Use-Case: online tickets

Master-Worker ‘event. X’ request ‘event. Y’ request Queue ‘event. Z’ request Workers are stateless + Self-tunable + Dynamic scalable + Resilient - Shared mutable state requires LOCKS Implementation tips: ride the Camel! (and your preferred distributed messaging infrastructure) 1 – Create your route 2 – Configure it to be local or distributed

Actor-Model ‘event. X’ request ‘event. Y’ request Actor Mail. Box ‘event. Z’ request Implementation tips: Akka Business Logic Actors are stateful + Shared Mutable State does not exist: no need for complex concurrency-aware logic. - Load should be partitioned at design time if possible (or implemented using Router-Actors, etc)

Comparison: which is the best? It depends… The best results come from choosing the concurrency model by the business process. Near-stateless, heavely loaded, business processes Master-Worker Statefull business processes Actor-Model

THANKS Questions?