scala - AKKA Actor y DataBase Operation

database-connection connection-pooling

Question

Estoy tratando de averiguar cómo manejar mejor las operaciones de la base de datos mientras uso un sistema actor. de hecho, las operaciones de la base de datos están bloqueando mientras intentamos no bloquear en AKKA.

Me di cuenta en la documentación principal de que una forma de manejar eso era crear un grupo de actores detrás de un enrutador, potencialmente en una ejecución separada, que manejaría el acceso a la base de datos.

Por eso tengo las siguientes preguntas:

1 - ¿Los databaseActors mantienen la conexión abierta todo el tiempo?

2 - ¿Cómo funciona junto con la agrupación de conexiones ofrecida por muchas bases de datos?

3 - Combinaremos ambos, y pediremos a los DatabaseActors que soliciten una nueva conexión del grupo cada vez que se soliciten. Si no es así, ¿no es malo mantener una conexión abierta en todo momento?

4 - ¿Puede alguien explicarme lo sutil que lo convierte en un enfoque que evita el hambre de hilos? Por ejemplo, al usar Play o Spray, el manejo de una solicitud es una tarea asíncrona. Sin embargo, si esa tarea necesita un acceso a la base de datos y enviamos una pregunta al DatabaseActor, el bloque en la base de datos Actor (si ocurre) no induce, ¿Un bloque en la tarea asíncrona, que conduce a una posible inanición de hilos?

5 - ¿Es 100% seguro que la propiedad DB ACID garantiza la seguridad de la lectura y escritura múltiple y, por lo tanto, sucede antes de la relación?

6 - Estoy usando la base de datos semántica también llamada triple tienda y uso intensivo de la capacidad de razonamiento semántico durante mi solicitud. También realizo una gran cantidad de acceso de escritura, algún consejo, sobre los parámetros de ajuste de los números de actor y agrupación o el contexto de ejecución dedicado.

Mejor,

METRO

Answer 1

1 - ¿Los databaseActors mantienen la conexión abierta todo el tiempo?

Los actores Akka son con estado , es decir, puede almacenar de forma segura el estado (en este caso, la conexión DB) dentro de un actor. Puede escribir su propia lógica de administración de conexión o usar la que le proporciona el controlador de su base de datos.

2 - ¿Cómo funciona junto con la agrupación de conexiones ofrecida por muchas bases de datos?

3 - Combinaremos ambos, y pediremos a los DatabaseActors que soliciten una nueva conexión del grupo cada vez que se soliciten. Si no es así, ¿no es malo mantener una conexión abierta en todo momento?

Puedes combinar ambos. Tener un actor para cada conexión en la piscina. ¿Por qué crees que tener una conexión viva es algo malo? El objetivo de tener un grupo de conexiones no es reutilizar los recursos (conexiones) y no pagar el precio de crearlos / destruirlos cada vez.

4 - ¿Puede alguien explicarme lo sutil que lo convierte en un enfoque que evita el hambre de hilos? Por ejemplo, al usar Play o Spray, el manejo de una solicitud es una tarea asíncrona. Sin embargo, si esa tarea necesita un acceso a la base de datos y enviamos una pregunta al DatabaseActor, el bloque en la base de datos Actor (si ocurre) no induce, ¿Un bloque en la tarea asíncrona, que conduce a una posible inanición de hilos?

Si el controlador de la base de datos está bloqueando, también tendrá que bloquear. La práctica recomendada es ejecutar este bloque de código en un contexto de ejecución / grupo de hilos por separado. O si tiene la opción, elija un almacén de datos que tenga un controlador de base de datos reactivo (por ejemplo, ReactiveMongo para MongoDB) que sea completamente asíncrono y sin bloqueo.

5 - ¿Es 100% seguro que la propiedad DB ACID garantiza la seguridad de la lectura y escritura múltiple y, por lo tanto, sucede antes de la relación?

No entiendo lo que quieres decir con esto.

6 - Estoy usando la base de datos semántica también llamada triple tienda y uso intensivo de la capacidad de razonamiento semántico durante mi solicitud. También realizo una gran cantidad de acceso de escritura, algún consejo, sobre los parámetros de ajuste de los números de actor y agrupación o el contexto de ejecución dedicado.

Definitivamente deberías usar un contexto de ejecución diferente. El giro de los parámetros realmente depende de su configuración de hardware y otras características específicas de su software (tipo de base de datos, base de datos remota vs base de datos incorporada, solicitudes / segundo, etc.).

No creo que exista una talla única para todos los despachadores de Akka. Es más un arte. Mi única recomendación es que te asegures de que no estés bloqueando en ningún lugar de tu código.

Answer 2

Esta publicación de blog tiene algunos puntos realmente buenos por qué no usar Actor por conexión de base de datos.

En particular, significa que necesita administrar el nivel de concurrencia en lugar de permitir que el grupo de conexión nativo lo maneje por usted. También puede inducirle a error a pensar que su código se ejecuta en paralelo mientras que, de hecho, su código se ejecuta en serie.