Si bien JDBC y otras tecnologías exponen API de bloqueo (principalmente debido a la espera de I/O), se está trabajando en el Project Loom. Loom presenta Fibers como una abstracción ligera que convertirá las API de bloqueo en no bloqueantes. Esto es posible mediante el cambio de pila tan pronto como una invocación golpea una API de bloqueo. Entonces, el Fiber subyacente intenta continuar en un flujo anterior que estaba usando una API de bloqueo.
El modelo de ejecución de Fiber reduce drásticamente la cantidad de hilos nativos requeridos. La consecuencia es una mejor escalabilidad y un comportamiento sin bloqueo, al descargar las llamadas de bloqueo a un ejecutor. Todo lo que necesitamos aquí es una API adecuada que permita el consumo de un JDBC sin bloqueo implementado con Fibras.
comsat-jdbc proporciona un contenedor de bloqueo de fibra de la API JDBC, para que pueda usar su conexión dentro de fibras en lugar de hilos Java normales.
¿Por qué harías eso? Debido a que las fibras son hilos livianos y puede tener muchas más fibras que hilos en su JVM. "Muchos más" significa que estamos hablando de millones frente a un puñado de miles.
Esto significa que tiene mucha más capacidad de concurrencia en su sistema para hacer otras cosas en paralelo mientras espera la ejecución de JDBC, ya sean cálculos simultáneos y/o paralelos (como el intercambio de mensajes de actores) o fibra -bloqueo de I/O (p. ej., servicio de solicitudes, invocación de microservicios, lectura de archivos a través de NIO en fibra o acceso a otras fuentes de datos habilitadas para fibra como MongoDB).
Las Fibras son una solución al problema de bloqueo de JDBC. Deberíamos hablar un poco más del proyecto Loom pero pero pero, esto es otra historia y va ha ser contada en otro post ...
