¿Es bueno poner las operaciones de jdbc en los actores?

Question

Estoy construyendo una aplicación web tradicional que realiza operaciones CRUD de base de datos a través de JDBC. Y me pregunto si es bueno poner las operaciones de jdbc en actores, fuera del hilo actual de procesamiento de solicitudes. Hice una búsqueda pero no encontré tutoriales o aplicaciones de muestra que muestren esto.

¿Cuáles son los contras y los pros? ¿Esta asincronización mejorará la capacidad del servidor de aplicaciones (es decir, la solicitud concurrente procesada) como nio?

Answer 1

Si poner acceso a JDBC en los actores es "bueno" o no depende en gran medida del resto de su aplicación.

La mayoría de las aplicaciones web actuales son síncronas, gracias al Servlet API que subyace a la mayoría de los marcos web Java (y Scala). Si bien ahora estamos viendo support for asynchronous servlets, ese soporte no ha funcionado en todos los marcos. A menos que comience con a framework that supports asynchronous processing, el procesamiento de su solicitud será sincrónico.

En cuanto a JDBC, JDBC is synchronous. De manera realista, nunca se hará nada al respecto, dada la carga que supondría la modificación de las implementaciones de controladores JDBC que existen en el mundo. Podemos esperar, pero no contengan la respiración.

Y las implementaciones JDBC no tienen que ser seguras para hilos, por lo que invocar una operación en una conexión JDBC antes de completar otra operación en la misma conexión dará como resultado un comportamiento indefinido. ¡Y un comportamiento indefinido! = Bueno.

Así que supongo que no verá las mismas mejoras de capacidad que ve con NIO.

Edición: acaba de descubrir adbcj; una API de controlador de base de datos asíncrona. Es un proyecto experimental escrito para una tesis de maestría, muy temprano, experimental. Es un experimento digno, y espero que tenga éxito. ¡Echale un vistazo!

Pero, si usted está construyendo una asíncrona, sistema basado en el actor, me gusta mucho la idea de tener acceso a datos o actores del repositorio, tanto de la misma manera como su hubiera data acccess o repository objetos en una capa Arquitectura OO.

Los actores garantizan que los mensajes se procesen de uno en uno, lo que es ideal para acceder a una sola conexión JDBC. (Una advertencia: la mayoría de los grupos de conexiones predeterminan la transmisión de conexión por hilo, que no funciona bien con los actores. En su lugar, deberá asegurarse de estar utilizando una conexión por actor. Lo mismo es cierto para la gestión de transacciones.)

Esto le permite tratar la base de datos como el sistema remoto asíncrono que deberíamos haber estado tratando desde el principio. Esto también significa que los resultados de sus actores de acceso/depósito de datos son futures, que son composable. Esto facilita la coordinación del acceso a datos con otras actividades asincrónicas.

Entonces, ¿es bueno? Probablemente, si se ajusta a la arquitectura del resto de su sistema. ¿Mejorará la capacidad? Eso dependerá de su sistema en general, pero parece un experimento muy valioso.