Asynchronous programming with Akka and Actors, in Play Framework

Part four of a series

All routes are by default asynchronous within Play. This means they do not block threads, unless you are dealing with Database calls — then Play can get a bit ‘mucky.’ This piece of code here from the Play docs fixes a lot of ills with Databases.

If you don’t know what Actors are, and you don’t know why Async programming is good, here’s the short version:

Applications run on a CPU (your computer’s brain). A CPU has a set of thread operations — you have a multi core CPU so you can (for argument’s sake) run one thread per core at once.

Think of a web server.

A request comes in from the outside world. The request takes a thread, the app then calls to the Database (DB) to get some data, but until the DB comes back with the data, that thread is blocked, it’s at the mercy of the database. We can’t serve any traffic on this thread until the DB has responded.

Requests queuing up on the web server showing a single core application

We have used a metaphor of a restaurant to show this behaviour. In this example the Waiting Staff represent the Web Server, the Kitchen represents the Database, and the Food represents the Data being requested.

Blocking IO in the form of a restaurant

The waiter takes the order, he walks to the kitchen and requests the food. The kitchen staff then create the dish. The whole time this is happening the waiter can’t do anything else as he is waiting for the food to be cooked.

This is a huge waste of resource.

Now the same path but with Actors.

Actors work by doing something amazing, they send messages to each other instead of waiting on results.

Non-Blocking IO in the form of a restaurant

In this example we show a similar restaurant setup. The waiter is still taking orders, but here he is passing the order to the kitchen as a message, and then forgets about it. This is a huge distinction from the first example!

Because, instead of waiting on the chefs to finish cooking each meal, the waiter can be alerted by the bell that it’s ready. The waiter is free to serve all of the other diners because now there’s a messaging system. He is no longer blocked from being able to serve other customers.

That’s why we use Actors.

An Akka workflow showing the restaurant as pictured above

In short:

• Request comes in
• Parent Actor passes message to pool of Child Actors or creates a new Child and passes the message directly to one
• Child Actor reads the message, calls the DB and stands aside, letting other traffic through
• When a message back to the server, the Child Actor wakes up
• The Child Actor then deals with the DB response, processes the response and passes back to the request

As shown above, in most applications the database is the slowest part. Just like spinning hard drives in computers, DBs take time to retrieve data. In Play you can use Actors to make the database client work in an asynchronous way, which will really increase the performance of your system.

Play (Java) is completely written around the CompletionStage class (a Java promise). Long ago it used the Scala promise, but it’s so nice to be written in the Java way now (since 2.3, I think).

Configuration docs can be seen here:
https://www.playframework.com/documentation/2.6.x/JavaDatabase#configuring-a-customexecutioncontext

In this example, we create a new Actor system named database.dispatcher. With Akka, you create pools of Actors that you can send messages to.

* Please also see the configuration needed in application.conf for the database dispatcher.

Here we add the execution context to the listAll method.

The code above is all you need to get every record from the Charity Table in the DB.

Let’s break it down:

We have stopped Database transactions ruining performance!

From here on in we have a super fast application with resources being managed really well and a database that is no longer such a bottleneck!

We have basically won the internet!

Next >> Putting it all together — Let’s serve a page