Leyendo la documentación del juego de reclamaciones:
http://www.playframework.org/documentation/2.0/ScalaAsync
"Debido a la forma en que funciona Play 2.0, el código de acción debe ser lo más rápido posible (es decir, sin bloqueo)".
Luego pasa a mostrar cómo escribir unResultado asíncrono. ¿Alguien podría ampliar por qué "el código de acción debe ser lo más rápido posible"? ¿Cómo afecta el cambio a un resultado asíncrono a la manera en que se maneja la solicitud en un nivel inferior? ¿Cuáles son los beneficios, además de la abstracción?
Respuestas
6 para la respuesta № 1En realidad, utilizando ASync para llamadas que pueden ser largas o asincrónicas por esencia (llame a otra API remota como twitter, db, ...) solo el cliente esperará, y no el servidor (como funciona Play 2.0)
Esto no afectará la forma en que se manejará la propia solicitud, sin embargo, toda la acción se ejecutará, ya que se prometerá el resultado para obtener más resultados, utilizando actores akka.
Este último punto es la clave, akka reutilizará tanto como sea posible los hilos disponibles en lugar de mantenerlos durmiendo.
Hablando de cómo estoy usando ASync mientras usoLa API REST de Neo4J para tratar con objetos persistentes, debido a que dicho uso de la base de datos depende de la red, el ancho de banda, el rendimiento de las consultas, ... puede ser complicado tener soluciones de alta disponibilidad, ya que la mayoría de las solicitudes están en espera. Que en la nube env. lo llevará a agregar procesos / instancias y finalmente le costará mucho ;-)