I will be very interested in how others respond to this question. > 2. Assuming no sharing state and only 1 actor per DB, then the approach would be to use Futures to process concurrent DB requests. Well that doesn't seem smart. You would have every single query or update all queued up waiting for a single actor/connection. Possibly your plan is to have the actor assign a connection to a future which might make it slightly better.
I have some Akka database code in development and haven't attempted some of these things. Currently, I have one database actor per table and they don't use a connection pool. It's my plan to have the actors grab a connection out of the pool using a normal Java call and then return it at the end. I was a bit interested about what your were planning to do with a circuit breaker. Note that the essence of the Netlfix circuit breaker is to return a sensible default value *for a command* if the breaker is open. That suggests that you would need to model your app with commands for each separate action so that your circuit breaker could have a default for that action. Cheers, Edward On Tuesday, June 10, 2014 3:23:00 AM UTC-7, Swaroop Belur wrote: > > Hello all, > > I am getting started on my first AKKA project and need some help. Found a > post related to database access , but could not conclude from that. > > I have an use case where I am trying to use AKKA to add resiliency in our > code base, where I need to access/update the database. > Assuming that I would create a pool of worker actors per database to > scale, each of these would need to share connection pool and also > circuit breaker [will have one per DB] . Reading the AKKA docs, my > understanding is that actors dont share state. > > Given this is it better to use actors (which will need to access 2 common > resources) or futures. > > 1. is it ok if Master DB actor for that DB creates a connection pool, > circuit breaker and passes these 2 during each DB execution in worker actor. > 2. Assuming no sharing state and only 1 actor per DB, then the approach > would be to use Futures to process concurrent DB requests. > 3. Is there any other approach ? > > Kindly provide some thoughts as its slightly unclear as of now. > > Thanks > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
