La Programación Reactiva, es el nuevo paradigma de moda, esencialmente, se refiere a la programación asíncrona. El hecho, es que la sintaxis funcional ayuda en gran medida con las cadenas de ejecución asíncrona SQL, y hoy en día, vamos a ver cómo podemos hacer esto en Java 8 haciendo uso de jOOQ y la nueva API CompletableFuture de Java.

¿Qué es JOOQ?

Antes de continuar, no sobra aclarar este nuevo paradigma, el cual ha sido adoptado por una variedad de programadores. Java Object Oriented Querying (Consulta Java Orientado a Objetos), comúnmente conocido como jOOQ, es una librería de software de base de datos, el cual implementa el patrón de registro activo. Su propósito es ser a la vez relacional y orientado al proporcionar un lenguaje de dominio específico para construir las consultas de clases, las cuales son generadas a partir de un esquema de base de datos de objetos.

Objetivo Ó Paradigma De JOOQ

JOOQ se asegura que el SQL debe ser lo primero en cualquier integración de bases de datos. Aunque proporciona abstracción sobre JDBC, JOOQ no tiene tanta funcionalidad y complejidad como las bibliotecas de mapeo objeto-relacional estándar como Hibernate y JPA.

Aun asi, JOOQ tiene grandes ventajas sobre librerías como Hibernate y JPA. Por la proximidad que tiene con SQL, jOOQ ayuda a evitar errores de sintaxis y los problemas de asignación de tipo. Además, la unión variables es atendida.

De hecho, las cosas son bastante simples:

// Initiate an asynchronous call chain
CompletableFuture

    // This lambda will supply an int value
    // indicating the number of inserted rows
    .supplyAsync(() -> DSL
        .using(configuration)
        .insertInto(AUTHOR, AUTHOR.ID, AUTHOR.LAST_NAME)
        .values(3, "Hitchcock")
        .execute()
    )
                          
    // This will supply an AuthorRecord value
    // for the newly inserted author
    .handleAsync((rows, throwable) -> DSL
        .using(configuration)
        .fetchOne(AUTHOR, AUTHOR.ID.eq(3))
    )

    // This should supply an int value indicating
    // the number of rows, but in fact it'll throw
    // a constraint violation exception
    .handleAsync((record, throwable) -> {
        record.changed(true);
        return record.insert();
    })
    
    // This will supply an int value indicating
    // the number of deleted rows
    .handleAsync((rows, throwable) -> DSL
        .using(configuration)
        .delete(AUTHOR)
        .where(AUTHOR.ID.eq(3))
        .execute()
    )

    // This tells the calling thread to wait for all
    // chained execution units to be executed
    .join();

Pero, ¿Que es lo que se realiza con el anterior código? Nada fuera de lo común. Existen 4 bloques de ejecución:

1. Uno que inserta un nuevo AUTOR.
2. Uno que obtiene ese mismo AUTOR.
3. Uno que re-inserta el AUTOR(lanza una excepción).
4. Uno que hace caso omiso de la excepción lanzada y eliminar el nuevo AUTOR.

Finalmente, cuando se establece la cadena de ejecución, el subproceso de llamada se unirá a toda la cadena utilizando el método CompletableFuture.join(), que es esencialmente el mismo método Future.get(), excepto que no lanza cualquier comprobación de una excepción.

Comparando Esto Con Otras API

Otras APIs como Slick Scala han usado funciones similares, tales como las llamadas a flatMap(). En este momento no imitaremos esas APIs ya que creemos que las nuevas APIs de Java 8. En concreto, al ejecutar SQL, conseguir la conexión y las sentencias, es la esencia de JOOQ. La semántica de bloques de ejecución asíncrona encadenadas.

Limites JDBC

Sin duda, siempre existirá una barrera de bloqueo de este tipo de soluciones, y es en sí mismo JDBC, la cual es muy difícil de convertir en un API asíncrona. De hecho, algunas bases de datos realmente apoyan ejecuciones de consultas asincrónicas, como suele suceder, una sola sesión de base de datos sólo puede ser utilizada por un solo hilo para una sola consulta a la vez.

Fuente: http://blog.jooq.org/2014/09/23/asynchronous-sql-execution-with-jooq-and-java-8s-completablefuture/