Patterns for Concurrent Reactive Process Design

by

Emanuele Gherardini

Actor Modelvs

Master Worker

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)

! Joshua Bloch

! Robert Martin

! Kent Beck

! Martin Fowler

! Martin Odersky ! Brian Goetz

Who I am… Really ^_-

31 Years old Software Engineer

Always a passionate and enthusiast student…

6 years of professional experience

Working @ Ringmaster:System Architect of the GTech Gaming Platform

Who I am… Really ^_-

DO NOT BELIEVE ME(try it!)

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-WorkerWorkers are stateless+ Self-tunable+ Dynamic scalable+ Resilient

- Shared mutable state requires LOCKS

Worker‘eventZ’request

Queue Worker

Worker‘eventX’request

‘eventY’request

‘eventX’request

‘eventY’request

‘eventZ’request

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

‘eventZ’request

‘eventX’request

‘eventY’request

‘eventX’request

‘eventY’request

‘eventZ’request

Business Logic

MailBox

Actor

Implementation tips: Akka

Actors are stateful+ Shared Mutable State does not exist: no need for complex concurrency-aware logic.

- Load should bepartitioned at design time if possible (or implemented using Router-Actors, etc)

Comparison: which is the best?

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

It depends…

THANKS

Questions?