¿Es posible la llamada jdbc asincrónica?

Question

Me pregunto si hay una manera de hacer llamadas asíncronas a una base de datos?

Por ejemplo, imagine que tengo una gran solicitud que lleva mucho tiempo procesar, deseo enviar la solicitud y recibir una notificación cuando la solicitud devuelva un valor (pasando un Listener/callback o algo) No quiero bloquear esperando a que la base de datos responda.

No considero que el uso de un grupo de subprocesos sea una solución porque no se escala, en el caso de solicitudes simultáneas pesadas esto generará una gran cantidad de subprocesos.

Nos enfrentamos a este tipo de problema con los servidores de red y hemos encontrado soluciones utilizando la llamada al sistema select/poll/epoll para evitar tener un hilo por conexión. Me pregunto cómo tener una función similar con la solicitud de la base de datos.

Nota: Soy consciente de que usar FixedThreadPool puede ser una buena solución, pero me sorprende que nadie haya desarrollado un sistema realmente asincrónico (sin el uso de un hilo adicional).

** Actualización **
Debido a la falta de soluciones prácticas reales, decidí crear una biblioteca (parte de fingle) yo mismo: finagle-mysql. Básicamente decodifica/decodifica solicitud/respuesta de mysql y usa Finagle/Netty debajo del capó. Se escala extremadamente bien incluso con una gran cantidad de conexiones.

Answer 1

No entiendo cómo alguno de los enfoques propuestos que envuelven las llamadas JDBC en Actores, ejecutores o cualquier otra cosa puede ayudar aquí. ¿Alguien puede aclararlo?

Seguramente el problema básico es que las operaciones JDBC bloquean en el socket IO. Cuando lo hace, bloquea el hilo que se ejecuta: el final de la historia. Cualquiera que sea el marco de ajuste que elijas usar, terminará con un hilo que se mantendrá ocupado/bloqueado por solicitud simultánea.

Si los controladores de base de datos subyacentes (MySql?) Ofrecen un medio para interceptar la creación del socket (ver SocketFactory) entonces imagino que sería posible construir una capa de base de datos accionada por evento asíncrono sobre la api JDBC pero tiene que encapsular todo el JDBC detrás de una fachada impulsada por un evento, y esa fachada no se vería como JDBC (después de que sería impulsada por un evento). El procesamiento de la base de datos se realizaría de manera asincrónica en un hilo diferente para la persona que llama, y ​​tendría que averiguar cómo crear un administrador de transacciones que no dependa de la afinidad de la secuencia de comandos.

Algo como el enfoque que menciono permitiría que incluso una sola hebra de fondo procesara una carga de ejecutables JDBC simultáneos. En la práctica, probablemente ejecute un conjunto de hilos para hacer uso de múltiples núcleos.

(Por supuesto, no estoy comentando la lógica de la pregunta original solo las respuestas que implican que la concurrencia en un escenario con bloqueo de IO es posible sin el usuario de un patrón de selector, más simple para resolver su típico Concurrencia JDBC y poner en un grupo de conexión del tamaño correcto).

---

Parece probable MySql hace algo en la línea que estoy sugiriendo --- http://code.google.com/p/async-mysql-connector/wiki/UsageExample

Answer 2

no hay apoyo directo en JDBC pero tienes múltiples opciones como MDB, ejecutores de Java 5.

"No considero que el uso de un grupo de subprocesos es una solución, ya que no escala, en el caso de solicitudes concurrentes pesadas esto generará una gran cantidad de hilos ".

Tengo curiosidad ¿por qué un conjunto de hilos limitados no va a escalar? Es un grupo, no thread-per-request, para engendrar un hilo por cada solicitud. He estado usando esto durante bastante tiempo en una aplicación de carga pesada y hasta ahora no hemos visto ningún problema.

Answer 3

Solo estoy pensando ideas aquí. ¿Por qué no podrías tener un conjunto de conexiones de bases de datos con cada una de ellas teniendo un hilo? Cada hilo tiene acceso a una cola. Cuando quiere hacer una consulta que lleva mucho tiempo, puede poner la cola y luego uno de los hilos la recogerá y manejará. Nunca tendrás demasiados hilos porque el número de tus hilos está limitado.

Editar: O mejor aún, solo una cantidad de hilos. Cuando un hilo ve algo en una cola, solicita una conexión del grupo y lo maneja.

Answer 4

Tal vez usted podría utilizar un sistema de mensajería asíncrona JMS, que escala muy bien, en mi humilde opinión:

• Enviar un mensaje a una cola, donde los suscriptores aceptar el mensaje, y ejecutar el proceso de SQL. Su proceso principal continuará ejecutándose y aceptando o enviando nuevas solicitudes.

• Cuando finaliza el proceso de SQL, puede ejecutar la ruta opuesta: enviar un mensaje a una ResponseQueue con el resultado del proceso, y un oyente del lado del cliente lo acepta y ejecuta el código de devolución de llamada.

Answer 5

Es imposible hacer una llamada asincrónica a la base de datos través de JDBC, pero se puede hacer llamadas asíncronas a JDBC con Actores (por ejemplo, el actor realiza llamadas a la base de datos a través de JDBC, y envía mensajes a los terceros, cuando las llamadas son más), o bien, si te gusta CPS, con pipelined futures (promises) (una buena aplicación es ScalazPromises)

no considero que el uso de un grupo de subprocesos es una solución beca usarlo no escala, en el caso de solicitudes concurrentes pesadas esto generará una gran cantidad de hilos.

Los actores de Scala por defecto están basados ​​en eventos (no basados ​​en hilos) - la programación de continuación permite crear millones de actores en una configuración de JVM estándar.

Si se orienta a Java, Akka Framework es una implementación de modelo Actor que tiene una buena API tanto para Java como para Scala.

---

Aparte de eso, la naturaleza síncrona de JDBC tiene mucho sentido para mí. El costo de una sesión de base de datos es mucho más alto que el costo de la cadena Java que se está bloqueando (ya sea en primer plano o en segundo plano) y esperando una respuesta. Si sus consultas se ejecutan durante tanto tiempo que las capacidades de un servicio de ejecutor (o envolviendo los marcos de concurrencia Actor/fork-join/promise) no son suficientes para usted (y está consumiendo demasiados hilos) primero debe pensar en su carga de la base de datos Normalmente, la respuesta de una base de datos vuelve muy rápido, y un servicio ejecutor respaldado con un grupo de subprocesos fijo es una solución lo suficientemente buena. Si tiene demasiadas consultas de larga ejecución, debe considerar el procesamiento previo (pre), como el recálculo nocturno de los datos o algo así.

Answer 6

El Java 5.0 executors puede ser útil.

Puede tener un número fijo de hilos para manejar operaciones de larga ejecución. Y en lugar de Runnable puede usar Callable, que devuelve un resultado. El resultado se encapsula en un objeto Future<ReturnType>, por lo que puede obtenerlo cuando vuelva.

Answer 7

Sólo una idea loca: Se podría utilizar un patrón de Iteratee sobre JBDC conjuntoResultados envuelto en algún futuro/Promise

Hammersmith lo hace por MongoBd.

Answer 8

La biblioteca Commons-dbUtils tiene soporte para un AsyncQueryRunner que usted proporciona una ExecutorService a y devuelve una Future . Vale la pena echarle un vistazo ya que es fácil de usar y garantiza que no se perderán recursos.

Answer 9

proyecto Ajdbc parece responder a este problema http://code.google.com/p/adbcj/

existe en la actualidad 2 experimentales conductores nativa asincrónicos para MySQL y PostgreSQL.

Answer 10

Una vieja pregunta, pero algo más de información. No es posible hacer que JDBC emita solicitudes asincrónicas a la base de datos, a menos que un proveedor proporcione una extensión a JDBC y un contenedor para manejar JDBC. Dicho esto, es posible ajustar JDBC con una cola de procesamiento e implementar una lógica que pueda procesar la cola en una o más conexiones separadas. Una ventaja de esto para algunos tipos de llamadas es que la lógica, si está suficientemente cargada, podría convertir las llamadas en lotes JDBC para su procesamiento, lo que puede acelerar la lógica significativamente. Esto es más útil para las llamadas donde se están insertando datos, y el resultado real solo se debe registrar si hay un error. Un buen ejemplo de esto es si se realizan inserciones para registrar la actividad del usuario. A la aplicación no le importará si la llamada finaliza inmediatamente o dentro de unos segundos.

Como nota al margen, un producto en el mercado proporciona un enfoque basado en políticas para permitir que las llamadas asíncronas como las que describí se hagan de forma asíncrona (http://www.heimdalldata.com/). Descargo de responsabilidad: soy cofundador de esta empresa. Permite aplicar expresiones regulares a las solicitudes de transformación de datos, como insertar/actualizar/eliminar para cualquier fuente de datos JDBC, y las agrupará automáticamente para su procesamiento. Cuando se usa con MySQL y la opción rewriteBatchedStatements (MySQL and JDBC with rewriteBatchedStatements=true), esto puede reducir significativamente la carga general en la base de datos.

Answer 11

tiene tres opciones en mi opinión:

1. utilizar un concurrent queue para distribuir mensajes a través de una pequeña y fija el número de hilos. Entonces, si tiene 1000 conexiones, tendrá 4 hilos, no 1000 hilos.
2. Haga el acceso a la base de datos en otro nodo (es decir, otro proceso o máquina) y haga que su cliente de base de datos haga asynchronous network calls a ese nodo.
3. Implemente un verdadero sistema distribuido a través de mensajes asíncronos. Para eso necesitarás una cola de mensajes como CoralMQ o Tibco.

Diclaimer: Soy uno de los desarrolladores de CoralMQ.

Answer 12

Aquí es un resumen de lo que una API JDBC no bloqueante podría parecerse a partir de Oracle presentó en JavaOne: https://static.rainfocus.com/oracle/oow16/sess/1461693351182001EmRq/ppt/CONF1578%2020160916.pdf

Por lo tanto, parece que, al final, las llamadas JDBC verdaderamente asíncronos de hecho será posible.