poolvsactorssystem.md

¿Pool de conexiones con actores?

• "But really, you shouldn’t use your ActorSystem‘s thread pool to manage the number of concurrent database queries either. Your ActorSystem should manage your Thread resources - your database connection pool should actually be what is used to manage database concurrency. It’s highly unlikely that your home grown concurrency system will be faster than BoneCP."
• "I just wrote a jdbc connection pool using akka. (...) I found that Akka version is slower than many other connection pool implementations such as tomcat-jdbc, BoneCP or even commons DBCP." -> Este está abierto a discusión. No hay muchos detalles de la implementación.
• Una discusión interesante en el grupo de usuarios de akka de un tipo que está intentando implementar algo parecido pero para Redis
• El envío de mensajes a actores es no determinista: no hay garantía de orden. Entonces, ¿una implementación con actores no rompería la "linearizability" de la BD?. Sería posible un escenario donde los mensajes "Remover registro 1" y "Actualizar registro 1" se procesen en cualquier orden. ( ¿Porque un pool de threads no tiene este problema? )
• ¿Cual es la ventaja concreta de manejar los errores del pool por medio de un actor supervisor? ¿Que manejo de errores se podría hacer que el lenguaje no soporte?

• Sobre el primer artículo: el argumento que hace sobre el pool de conexiones se me hace endeble (yo ni siquiera incluiría el ActorSystem) pero coincido con la conclusión general: Los actores son para manejar estado (que requiere control de concurrencia) y los futuros para concurrencia sin estado (Esto hace parte de otra discusión pero igual me parecía importante traerlo a colación).
• En el caso específico de un RDBMS ¿uno porque querría utilizar un pool de conexiones que le baje las garantías de consistencia? Si la consistencia no es una preocupación fuerte ¿no valdría la pena en primer lugar utilizar algún repositorio NoSQL?
• Por otra parte utilizar vector clocks creo que tendría sentido pero solo a partir de los clientes externos del sistema de actores (para evitar el desorden potencial de mensajes que sucede dentro del sistema). Habría que ser más específico en el uso que se les da. Supongo que en general eso debe ser exageradamente fácil como para que lo estén proponiendo.