Hi,
I am coming from Java and am new to Scala and Akka and asynchronous
programming in general.
I have a threadsafe, async db client like this:
class Client{
...
def get(key: K): Future[Option[V]] = ...
}
I would like embed this functionality in an Actor.
My initial thoughts are something like this:
class MyDBClient extends Actor{
val client = Client( "102.98.2.1:3000" )
def receive = {
case ReadCommand( id ) =>
val orig_sender = sender
val f:Future[Option[String]] = client.get( id )
f pipeTo orig_sender
case _ =>
}
}
And I would have a pool of these actors like this:
class DBManager extends Actor{
var router = {
val routees = Vector.fill(5) {
val r = context.actorOf( Props[MyDBClient] )
context watch r
ActorRefRoutee(r)
}
Router( RoundRobinRoutingLogic(), routees )
}
def receive = {
case DoSomething( id ) => {
router.route( ReadCommand( id ), sender() )
}
case _ =>
}
I have an actor which requires the database parameter to calculate a click
value:
class ConfirmationCalc( dbClient:ActorRef ) extends Actor{
def receive:Receive = {
case CalculateFor( id ) =>
val orig_sender = sender
val f = ( dbClient ? ReadCommand( id ) )mapTo[Option[String]]
f.onComplete{
case Success( result ) => result match {
case Some( click ) =>
println( "Success: calculate using {}", click )
orig_sender ! calculate( click )
case None =>
println( "Got Empty" )
case Failure( e ) =>
e.printStackTrace()
}
case _ =>
}
def calculate( click:String ):BigDecimal = {...}
}
My questions are:
1. Is this the "correct" pooling architecture - that is, having a central
router that delegates to a number of dbactors which have a "connection" to the
database? Are there other architectures given that each DB Client class
controls its own connections?
2. ConfirmationCalc actor will be furiously processing "CalculateFor" messages.
I understand that the future will eventually complete with either Success or
Failure or timeout. My newbie question is after I process my first message in
ConfirmationCalc and send the async request to the dbclient, ConfirmationCalc
may be processing its second message when the future completes. In my newbie
opinion, this code would have concurrency issues since I would be getting the
first message's db results when processing the second message and send back the
first results to the sender who is expecting the second results. I have read
about "Cameo" patterns that encapsulate state within actors but "ask" does not
allow me to send the cameo in the ask. What code would address this issue ( if
it is one at all ?)
3. This is related to my previous question. In asynchronous systems, we might
have ActorA asking ActorB asking ActorC asking ActorD. I find it a bit mind
bending how each actor in the chain is going to maintain state of futures.
Future A may have onCompletions triggered thousands of times while it is
processing a message. Is there example code somewhere that addresses this?
Thanks
David
--
>>>>>>>>>> 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.
