scala - programacion - Uso de actores Akka en una aplicación web CRUD

akka tutorial

Question

Estoy trabajando en una aplicación web escrita en Scala, usando el juego! Marco y Akka. El código está organizado básicamente así: los controladores de juego envían mensajes a los actores Akka. Los actores, a su vez, hablan a una capa de persistencia, que abstrae el acceso a la base de datos. Un ejemplo típico del uso de estos componentes en la aplicación:

class OrderController(orderActor: ActorRef) extends Controller {
def showOrders(customerId: Long) = {
implicit request => Async {
val futureOrders = orderActor ? FindOrdersByCustomerId(id)
// Handle the result, showing the orders list to the user or showing an error message.
}
}
}
object OrderActor extends Actor {
def receive = {
case FindOrdersByCustomerId(id) =>
sender ! OrderRepository.findByCustomerId(id)
case InsertOrder(order) =>
sender ! OrderRepository.insert(order)
//Trigger some notification, like sending an email. Maybe calling another actor.
}
}
object OrderRepository {
def findByCustomerId(id: Long): Try[List[Order]] = ???
def insert(order: Order): Try[Long] = ???
}

Como puede ver, este es el patrón básico de CRUD, muy parecido a lo que vería en otros lenguajes y marcos. Una consulta pasa a las capas de abajo y, cuando la aplicación obtiene un resultado de la base de datos, ese resultado vuelve a aparecer hasta que alcanza la interfaz de usuario. La única diferencia relevante es el uso de actores y llamadas asíncronas.

Ahora, soy muy nuevo en el concepto de actores, así que todavía no lo entiendo. Pero, por lo que he leído, no es así como se supone que se usan los actores. Observe, sin embargo, que en algunos casos (por ejemplo, enviar un correo electrónico cuando se inserta un pedido) necesitamos un verdadero paso asíncrono de mensajes.

Entonces, mi pregunta es: ¿es una buena idea usar actores de esta manera? ¿Cuáles son las alternativas para escribir aplicaciones CRUD en Scala, aprovechar los futuros y las otras capacidades de concurrencia de Akka?

Answer 1

Aunque la concurrencia basada en el actor no encaja con las operaciones transaccionales fuera de la caja, pero eso no le impide utilizar a los actores de esa manera si juega bien con la capa de persistencia. Si puede garantizar que el inserto (escritura) es atómico, entonces puede tener un grupo de actores que lo hagan por usted de manera segura. Normalmente, las bases de datos tienen una lectura segura de subprocesos, por lo que buscar también debería funcionar como se espera. Además, si la inserción no es segura para subprocesos, puede tener un solo WriteActor dedicado simplemente para operaciones de escritura y el procesamiento secuencial de los mensajes garantizará la atomicidad para usted.

Answer 2

Una cosa a tener en cuenta es que un actor procesa un mensaje a la vez, lo que sería bastante limitante en este caso. Puedes usar un grupo de actores usando routers .

Su ejemplo define una api de bloqueo del repositorio, que podría ser lo único que puede hacer, dependiendo de su controlador de base de datos. Si es posible, debería ir allí también para obtener una api asíncrona, es decir, devolver futuros. En el actor, en lugar de eso, pipe el resultado del futuro al remitente.