Slide 1

Slide 1 text

So how do I do a 2PC in Akka then? or Lutz Hühnken (@lutzhuehnken) A Pragmatic View of Reactive

Slide 2

Slide 2 text

So how do I do a 2PC in Akka then? Lutz Hühnken (@lutzhuehnken) A misleading title, really. Answer: You don’t want to (we’ll get back to that later)

Slide 3

Slide 3 text

Valuable Experience vs. Bad Habit From Enterprise to Reactive Transitions … Lutz Hühnken (@lutzhuehnken) Other failed naming attempts..

Slide 4

Slide 4 text

Lutz Hühnken (@lutzhuehnken) A Pragmatic View of Reactive

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

Yes, of course. But who doesn’t claim that for their system?

Slide 7

Slide 7 text

Come on. Now you’re just selling Akka to me..

Slide 8

Slide 8 text

Real, Pragmatic Questions WAR? Servlet Container? Library X (which uses ThreadLocal) ? RDBMS/ JDBC? How to do 2PC?

Slide 9

Slide 9 text

Pragmatic Problem Fields Deployment Concurrency Model I/O Distribution

Slide 10

Slide 10 text

The Pragmatic Reactive Manifesto

Slide 11

Slide 11 text

Threads vs. task level concurrency

Slide 12

Slide 12 text

Pragmatic Reactive Threads … A supposedly great idea • Threads are • lightweight processes • easier programming model, no IPC 12

Slide 13

Slide 13 text

Pragmatic Reactive Lightweight? 13 Slide from John Rose, Java VM Architect, JFokus, Stockholm, February 2015

Slide 14

Slide 14 text

Pragmatic Reactive The problem with Threads 14 They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism.

Slide 15

Slide 15 text

+ Let’s talk about Multi-Threading Every time…

Slide 16

Slide 16 text

Pragmatic Reactive Threads • not efficient • memory consumption • cost for context switch • bad match modern NUMA architectures • locks lead to contention
 • not a good programming model • shared mutual state is difficult to reason about 16

Slide 17

Slide 17 text

Pragmatic Reactive What would be better? Goals • task level (sub-thread) concurrency • share nothing approach • # threads ~ # of cores 17

Slide 18

Slide 18 text

Pragmatic Reactive Thread alternatives (successors?) • Green threads / coroutines / fibres • other granularity, but basically same programming model • Event-loop (e.g. vert.x, Reactor) • very loose coupling, slightly limited, 1 x n dispatch • Actors ! • truly share-nothing, flexible, resilience-proven, 
 m x n dispatch 18

Slide 19

Slide 19 text

Pragmatic Reactive Example: Http Request handling Java EE: Threads. Servlet API: Thread per Request 19 Note: This is a snapshot at one point in time, not a sequence of events.

Slide 20

Slide 20 text

Pragmatic Reactive Example: Http Request handling Reactive: Sub-Thread. Play: n threads per m requests 20 Note: This is a snapshot at one point in time, not a sequence of events.

Slide 21

Slide 21 text

Pragmatic Reactive Consequences • We have effectively (even without explicitly using Actors) switched to a task level concurrency model • As a consequence, ThreadLocal becomes an anti-pattern. • Libraries that depend on them need extra work, might better be avoided • What does it mean for (blocking) I/O? 21

Slide 22

Slide 22 text

Pragmatic Reactive Pragmatic reactive learnings cont’d • You’ll be using sub-thread level concurrency. Accept it, embrace it. 22

Slide 23

Slide 23 text

Blocking vs. non-blocking I/O

Slide 24

Slide 24 text

Pragmatic Reactive High concurrency matters 24 But there’s one thing we can all agree on: At high levels of concurrency (thousands of connections) your server needs to go to asynchronous non-blocking. [..] any part of your server code blocks you’re going to need a thread. And at these levels of concurrency, you can’t go creating threads for every connection. From https://strongloop.com/strongblog/node-js-is-faster-than-java/

Slide 25

Slide 25 text

Pragmatic Reactive Blocking I/O Reactive: Sub-Thread. Play: n threads per m requests 25 What does using blocking I/O mean for this?

Slide 26

Slide 26 text

Pragmatic Reactive Non-blocking 26 For task level (sub-thread level) concurrency • each thread is responsible for n tasks • and that n might be pretty big You don’t want to block such a thread with blocking I/O

Slide 27

Slide 27 text

Pragmatic Reactive But what if I need this..? 27 try { stmt = con.createStatement(); ResultSet rs = stmt.executeQuery(query); while (rs.next()) { String coffeeName = rs.getString("COF_NAME"); int supplierID = rs.getInt("SUP_ID"); float price = rs.getFloat("PRICE"); int sales = rs.getInt("SALES"); int total = rs.getInt("TOTAL"); System.out.println(coffeeName + "\t" + supplierID + "\t" + price + "\t" + sales +

Slide 28

Slide 28 text

Pragmatic Reactive Isolate! 28 vert.x has „worker verticles“ Play/Akka: Configure Dispatchers Slick 3 takes care of this for you!

Slide 29

Slide 29 text

Pragmatic Reactive Pragmatic reactive learnings cont’d • You’ll be using sub-thread level concurrency. Accept it, embrace it. • Use asynchronous I/O. If you really can’t, isolate. 29

Slide 30

Slide 30 text

„Distributed Transactions“ vs. Distributed Systems

Slide 31

Slide 31 text

Pragmatic Reactive But what if I need this..? 31 @Transactional public static class GreetingService { @Inject private JmsTemplate jmsTemplate; @PersistenceContext private EntityManager entityManager; public void createGreeting(String name) { Greeting greeting = new Greeting(name); this.entityManager.persist(greeting); this.jmsTemplate.convertAndSend("greetings", greeting); …

Slide 32

Slide 32 text

Pragmatic Reactive Avoid, separate, recycle.. 32

Slide 33

Slide 33 text

Pragmatic Reactive Avoid… 33 @Transactional public static class GreetingService { @Inject private JmsTemplate jmsTemplate; @PersistenceContext private EntityManager entityManager; public void createGreeting(String name) { Greeting greeting = new Greeting(name); this.entityManager.persist(greeting); this.jmsTemplate.convertAndSend("greetings", greeting); … The example: In fact not really all-or-nothing, but reconciliation.

Slide 34

Slide 34 text

Pragmatic Reactive Separate (the steps..) 34 Claim: Any 2PC can be expressed in terms of asynchronous messaging.

Slide 35

Slide 35 text

Pragmatic Reactive Life beyond Distributed Transactions 35 In general, application developers simply do not implement large scalable applications assuming distributed transactions. When they attempt to use distributed transactions, the projects founder because the performance costs and fragility make them impractical. [..]

Slide 36

Slide 36 text

36 Want Almost-Infinite Scaling
 • More of everything… Year by year, bigger and bigger • If it fits on your machines, multiply by 10, if that fits, multiply by 1000… • Strive to scale almost linearly (N log N for some big log). Assumptions
 (Don’t Have to Prove These… Just Plain Believe Them) Grown-Ups Don’t Use Distributed Transactions •The apps using distributed transactions become too fragile… • Let’s just consider local transactions. ! Multiple disjoint scopes of serializability Want Scale-Agnostic Apps
 • Two layers to the application: 
 scale-agnostic and scale-aware • Consider scale-agnostic API Scale Agnostic Code Scale-Aware-Code Application Upper Layer Lower Layer Scale Agnostic API

Slide 37

Slide 37 text

Pragmatic Reactive 2 PC => messaging 37 Item-B Cancellation Tentative Op Item-A Restrictions / Requirements •at-least-once delivery •idempotent messages •tentative operations

Slide 38

Slide 38 text

Pragmatic Reactive Pragmatic 38 Real world solution: Saga Pattern Source: http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/

Slide 39

Slide 39 text

Pragmatic Reactive Pragmatic 39 Example (by Caitie McCaffrey) Source: https://speakerdeck.com/caitiem20/applying-the-saga-pattern

Slide 40

Slide 40 text

Pragmatic Reactive Distributed Transactions 40 Distributed Transactions („2PC“) are a source of unnecessary failure and of contention. It can usually be avoided. Generally, local transactions and at-least-once delivery can be used instead. The Saga Pattern provides a pragmatic solution for „all-or- nothing“ in a distributed system.

Slide 41

Slide 41 text

Pragmatic Reactive Food for thought 41 The data storage landscape is changing, moving towards event sourcing and immutability. This is a great match for reactive systems. The „all-or-nothing“ problems are closely related to wanting a global truth at a point in time. But what is now… the illusion of present… result of series of events..

Slide 42

Slide 42 text

Pragmatic Reactive Pragmatic reactive learnings cont’d • You’ll be using sub-thread level concurrency. Accept it, embrace it. • Use asynchronous I/O. If you really can’t, isolate. • Do not use distributed transactions. If you really must, isolate. 42

Slide 43

Slide 43 text

App Servers vs. Standalone

Slide 44

Slide 44 text

Pragmatic Reactive 44

Slide 45

Slide 45 text

Pragmatic Reactive 45

Slide 46

Slide 46 text

Pragmatic Reactive Java EE Application Servers 46 Servlet API was developed for thread-per- request, synchronous I/O. Application servers are not of much use anyway, nobody uses them as containers for multiple applications. So effectively they’re just a library dependency. The ops convenience can be provided by other tools.

Slide 47

Slide 47 text

Pragmatic Reactive Pragmatic reactive learnings cont’d • You’ll be using sub-thread level concurrency. Accept it, embrace it. • Use asynchronous I/O. If you really can’t, isolate. • Do not use distributed transactions. If you really must, isolate. • Don’t use an application server / servlet container. 47

Slide 48

Slide 48 text

Summary

Slide 49

Slide 49 text

Pragmatic Reactive Conclusion 49 If • Threads are the smallest unit of concurrency in your code, or • You use blocking I/O (without clear separation), or • You use 2-phase-commit across systems, or • You use a Java EE Application Server / Servlet Container Then your application is not reactive.

Slide 50

Slide 50 text

Pragmatic Reactive The Pragmatic Reactive Checklist 50 • Task-level (sub-thread level) concurrency • Non-blocking I/O • Distributed • Containerless

Slide 51

Slide 51 text

Reactive Manifesto revisited

Slide 52

Slide 52 text

We really only talked about the elastic part

Slide 53

Slide 53 text

will lead to will lead to

Slide 54

Slide 54 text

Thank you Lutz Hühnken (@lutzhuehnken)