AKKA Actor and DataBase Operation

Question

I'm trying to figure out how to best handle database operations while using an actor system. indeed database operations are blocking while we try not to block in AKKA.

I red in the main doc that one way to handle that was to create one a pool of actors behind a router, potentially on a separated executionContext, that would handle database access.

Therefore i have the following questions:

1 - Does the databaseActors keep the connection open the all time?

2 - How does it work together with connection Pooling as offered by many database?

3 - Shall we combine both, and have the DatabaseActors request a new connection from the pool each time they are solicited. If not, isn't it keeping a connection open at all time a bad thing to do?

4 - Can someone explain to me the subtle thing that make it an approach that avoid thread starvation. For instance using Play or spray, the handling of a request is an asynchronous task, however if that task need a database access and we send an ask to the DatabaseActor, does the block on the database Actor (if it occur) do not induce, a block in the asynchronous task, leading to possible thread starvation ?

5 - Is it 100% sure the DB ACID property ensures the safety of the multiple read and write and therefore happens before relationship.

6 - I'm using the semantic database also called triple store and make heavy using of semantic reasoning capability during my request. I also perform a lot of write access, any advise, concerning tuning parameters of pooling and actor numbers or dedicated execution context?

Best,

M

Answer 1

1 - Does the databaseActors keep the connection open the all time?

Akka actors are stateful i.e., you can safely store state (in this case DB connection) inside an actor. You can either write you own connection management logic or use the one that is provided by the your database driver.

2 - How does it work together with connection Pooling as offered by many database?

3 - Shall we combine both, and have the DatabaseActors request a new connection from the pool each time they are solicited. If not, isn't it keeping a connection open at all time a bad thing to do?

You can combine both. Have an actor for each connection in the pool. Why do you think having a connection alive is a bad thing? Isn't the whole point of having a connection pool is to reuse resources (connections) and not pay the price of creating/destroying them every time.

4 - Can someone explain to me the subtle thing that make it an approach that avoid thread starvation. For instance using Play or spray, the handling of a request is an asynchronous task, however if that task need a database access and we send an ask to the DatabaseActor, does the block on the database Actor (if it occur) do not induce, a block in the asynchronous task, leading to possible thread starvation ?

If your database driver is blocking then you eventually have to block also. The recommended practice is to execute this blocking piece of code in a separate execution context/thread pool. Or if you have the option choose a datastore that has a reactive database driver (e.g., ReactiveMongo for MongoDB) which is completely async and non-blocking.

5 - Is it 100% sure the DB ACID property ensures the safety of the multiple read and write and therefore happens before relationship.

I don't understand what you mean by this.

6 - I'm using the semantic database also called triple store and make heavy using of semantic reasoning capability during my request. I also perform a lot of write access, any advise, concerning tuning parameters of pooling and actor numbers or dedicated execution context?

You should definitely use a different execution context. The turning of parameters really depends on your hardware configuration and other specifics of your software (type of database, remote db vs embedded db, requests/second etc).

I don't think there is a one size fits all when it comes to Akka dispatchers. It's more of an art. My only recommendation is that make sure you are not blocking anywhere in your code.

Answer 2

This blog post has some really good points why not to use Actor per DB connection.

In particular, it means you need to manage the concurrency level instead of letting the native connection pool to handle it for you. It also may mislead you to think your code runs in parallel while in fact your code runs serially.