Menu
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
608
Akka ensures that each instance of an actor runs in its own lightweight thread and that messages are processed one at a time. In this way, each actor's state can be reliably maintained without the developer needing to explicitly worry about synchronization or race conditions.
Akka actors use java threads internally. More than a few thousand threads running simultaneously produces overhead on most desktop machines. Akka Actors simplifies this problem by providing awake-on-demand actors who do not occupy a thread unless they have some work to do.
Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala.
Props is a configuration object using in creating an Actor; it is immutable, so it is thread-safe and fully shareable.
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.
101
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.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
