Thanks Patrik Since I am using spring jdbc, I dont have direct control of obtaining connection as well. So i think point 3 would be difficult to do. I think i will use futures for this.
So just to understand completely - when you say circuitbreaker is used w/ Futures, so in an actor only scenario, what would the approach if circuitbreaker is not to be used. Not sure i misunderstood. (Just in case i used actors for this, but using circuitbreaker is essential as I want to fail fast as well) On Wednesday, 11 June 2014 16:50:40 UTC+5:30, Patrik Nordwall wrote: > > I assume that you are using JDBC, and that means blocking of the thread > until the db call returns. Therefore (and possibly for other reasons) you > want to limit the number of concurrent calls to the database. That can be > done by using a limited number of actors or running the actors or futures > on a dedicated dispatcher (thread pool). > > To handle the db connections I see 3 options: > 1. use a connection pool, which is thread safe and can therefore be shared > and used from multiple actors/futures > 2. have each actor manage its own connection (no connection pool) > 3. have one actor that manages the connections (with or without pool) and > let other actors borrow a connection for a while and then return it back > > It might be easier to use futures for blocking jdbc calls, but if you need > more fine grained control of error handling and bulk heading actors have > some advantages. The akka CircuitBreaker is designed for futures. > > Cheers, > Patrik > > > On Tue, Jun 10, 2014 at 9:57 PM, Edward Sargisson <[email protected] > <javascript:>> wrote: > >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > Patrik Nordwall > Typesafe <http://typesafe.com/> - Reactive apps on the JVM > Twitter: @patriknw > > <http://www.scaladays.org/> > > -- >>>>>>>>>> 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.
