È possibile la chiamata asincrona jdbc?

Mi chiedo se esiste un modo per effettuare chiamate asincrone a un database?

Ad esempio, immagina di avere una grande richiesta che impiega molto tempo per l'elaborazione, voglio inviare la richiesta e ricevere una notifica quando la richiesta restituirà un valore (passando un Listener / callback o qualcosa del genere). Non voglio bloccare in attesa che il database risponda.

Non ritengo che l'uso di un pool di thread sia una soluzione perché non si adatta, nel caso di richieste simultanee pesanti ciò genererà un numero molto elevato di thread.

Stiamo affrontando questo tipo di problema con i server di rete e abbiamo trovato soluzioni usando la chiamata di sistema select / poll / epoll per evitare di avere un thread per connessione. Mi sto solo chiedendo come avere una funzione simile con la richiesta del database?

Nota: sono consapevole del fatto che l'utilizzo di FixedThreadPool può essere una buona soluzione, ma sono sorpreso che nessuno abbia sviluppato un sistema veramente asincrono (senza l'utilizzo di thread aggiuntivi).

** Aggiornamento **
A causa della mancanza di soluzioni pratiche concrete, ho deciso di creare una libreria (parte di finagle) da solo: finagle-mysql . Fondamentalmente decodifica / decodifica richiesta / risposta mysql e usa Finagle / Netty sotto il cofano. Ridimensiona estremamente bene anche con un numero enorme di connessioni.

Non capisco come nessuno degli approcci proposti che avvolgono le chiamate JDBC in attori, esecutori o qualsiasi altra cosa possa aiutare qui - qualcuno può chiarire.

Sicuramente il problema di base è che le operazioni JDBC si bloccano sul socket IO. Quando lo fa, blocca il thread che sta funzionando - fine della storia. Qualunque framework di wrapping tu scelga di usare, finirà con un thread tenuto occupato / bloccato per richiesta simultanea.

Se i driver di database sottostanti (MySql?) Offrono un modo per intercettare la creazione del socket (vedi SocketFactory), allora immagino che sarebbe possibile costruire un livello di database guidato dagli eventi asincroni sopra l'API JDBC ma dovremmo incapsulare il tutto il JDBC dietro una facciata guidata dagli eventi, e quella facciata non assomiglierebbe al JDBC (dopo che sarebbe stata guidata dagli eventi). L'elaborazione del database avverrebbe in modo asincrono su un thread diverso dal chiamante e dovresti capire come costruire un gestore delle transazioni che non si basa sull'affinità del thread.

Qualcosa come l'approccio che menziono consentirebbe anche a un singolo thread in background di elaborare un carico di exec JDBC simultanei. In pratica, avresti probabilmente eseguito un pool di thread per utilizzare più core.

(Ovviamente non sto commentando la logica della domanda originale, ma solo le risposte che implicano che la concorrenza in uno scenario con socket IO bloccante è possibile senza l'utente di un modello di selezione - più semplice solo per elaborare la tipica concorrenza JDBC e mettere in un pool di connessioni della giusta dimensione).

Sembra che MySql probabilmente faccia qualcosa sulla falsariga che sto suggerendo --- http://code.google.com/p/async-mysql-connector/wiki/UsageExample

È impossibile effettuare una chiamata asincrona al database tramite JDBC, ma è possibile effettuare chiamate asincrone a JDBC con Actors (ad esempio, attore effettua chiamate al DB tramite JDBC e invia messaggi a terzi, quando le chiamate sono terminate), o, se ti piace CPS, con futures pipeline (promesse) (una buona implementazione è Scalaz Promises )

Non ritengo che l'uso di un pool di thread sia una soluzione perché non si adatta, nel caso di richieste simultanee pesanti ciò genererà un numero molto elevato di thread.

Gli attori Scala per impostazione predefinita sono basati su eventi (non basati su thread): la pianificazione della continuazione consente di creare milioni di attori su una configurazione JVM standard.

Se hai come target Java, Akka Framework è un'implementazione del modello Actor che ha una buona API sia per Java che per Scala.

A parte questo, la natura sincrona di JDBC ha perfettamente senso per me. Il costo di una sessione del database è di gran lunga superiore al costo del thread Java bloccato (in primo piano o in background) e in attesa di una risposta. Se le tue query vengono eseguite così a lungo che le capacità di un servizio di esecuzione (o il wrapping di framework di concorrenza Actor / fork-join / promise) non sono sufficienti per te (e stai consumando troppi thread), dovresti prima di tutto pensare al tuo caricamento del database. Normalmente la risposta da un database ritorna molto velocemente e un servizio di esecuzione eseguito da un pool di thread fisso è una soluzione abbastanza buona. Se hai troppe query di lunga durata, dovresti considerare l'elaborazione (pre) anticipata, come il ricalcolo notturno dei dati o qualcosa del genere.

Forse potresti usare un sistema di messaggistica asincrono JMS, che si adatta abbastanza bene, IMHO:

• Invia un messaggio a una coda, in cui gli abbonati accetteranno il messaggio ed eseguiranno il processo SQL. Il processo principale continuerà a essere eseguito e ad accettare o inviare nuove richieste.

• Al termine del processo SQL, è possibile eseguire la procedura opposta: inviare un messaggio a ResponseQueue con il risultato del processo e un ascoltatore sul lato client lo accetta ed esegue il codice di richiamata.

Non esiste un supporto diretto in JDBC ma hai più opzioni come MDB, Executors da Java 5.

"Non ritengo che l'utilizzo di un pool di thread sia una soluzione perché non si adatta, nel caso di richieste simultanee pesanti ciò genererà un numero molto elevato di thread".

Sono curioso di sapere perché un pool limitato di thread non si ridimensionerà? È un pool non thread-per-richiesta per generare un thread per ogni richiesta. Ho usato questo per un po 'di tempo su una webapp di carico pesante e finora non abbiamo riscontrato alcun problema.

Sembra che una nuova API asincrona jdbc "JDBC next" è in lavorazione.

Vedi la presentazione qui

Puoi scaricare l'API da qui

Come menzionato in altre risposte, l'API JDBC non è asincrona per sua natura.
Tuttavia, se riesci a convivere con un sottoinsieme delle operazioni e un'API diversa ci sono soluzioni. Un esempio è https://github.com/jasync-sql/jasync-sql che funziona per MySQL e PostgreSQL.

Il progetto Ajdbc sembra rispondere a questo problema http://code.google.com/p/adbcj/

Al momento ci sono 2 driver sperimentali nativi asincroni per mysql e postgresql.

Una vecchia domanda, ma qualche informazione in più. Non è possibile che JDBC emetta richieste asincrone al database stesso, a meno che un fornitore non fornisca un'estensione a JDBC e un wrapper con cui gestire JDBC. Detto questo, è possibile racchiudere JDBC stesso con una coda di elaborazione e implementare una logica in grado di elaborare la coda su una o più connessioni separate. Un vantaggio di questo per alcuni tipi di chiamate è che la logica, se sotto carico abbastanza pesante, potrebbe convertire le chiamate in batch JDBC per l'elaborazione, il che può accelerare significativamente la logica. Ciò è molto utile per le chiamate in cui vengono inseriti i dati e il risultato effettivo deve essere registrato solo in caso di errore. Un ottimo esempio di ciò è se vengono eseguiti inserti per registrare l'attività dell'utente. L'applicazione ha vinto '

Come nota a margine, un prodotto sul mercato offre un approccio guidato dalle politiche per consentire chiamate asincrone come quelle che ho descritto per essere fatte in modo asincrono ( http://www.heimdalldata.com/ ). Disclaimer: sono cofondatore di questa azienda. Consente di applicare espressioni regolari alle richieste di trasformazione dei dati come inserire / aggiornare / eliminare per qualsiasi origine dati JDBC e raggrupparle automaticamente per l'elaborazione. Se utilizzato con MySQL e l'opzione rewriteBatchedStatements ( MySQL e JDBC con rewriteBatchedStatements = true ), ciò può ridurre significativamente il carico complessivo sul database.

Hai tre opzioni secondo me:

1. Utilizzare una coda simultanea per distribuire i messaggi su un numero limitato e fisso di thread. Quindi se hai 1000 connessioni avrai 4 thread, non 1000 thread.
2. Eseguire l'accesso al database su un altro nodo (ovvero un altro processo o macchina) e fare in modo che il client del database effettui chiamate di rete asincrone a quel nodo.
3. Implementare un vero sistema distribuito tramite messaggi asincroni. Per questo avrai bisogno di una coda di messaggistica come CoralMQ o Tibco.

Diclaimer: sono uno degli sviluppatori di CoralMQ.

È stata sviluppata una soluzione per rendere possibile la connettività reattiva con database relazionali standard.

Le persone che desiderano ridimensionare mantenendo l'utilizzo dei database relazionali sono tagliate fuori dalla programmazione reattiva a causa degli standard esistenti basati sul blocco dell'I / O. R2DBC specifica una nuova API che consente il codice reattivo che funziona in modo efficiente con i database relazionali.

R2DBC è una specifica progettata da zero per la programmazione reattiva con database SQL che definiscono una SPI non bloccante per gli implementatori di driver di database e gli autori di librerie client. I driver R2DBC implementano completamente il protocollo del filo del database su un livello I / O non bloccante.

Sito Web di R2DBC

GitHub di R2DBC

Feature Matrix

Gli esecutori Java 5.0 potrebbero tornare utili.

È possibile disporre di un numero fisso di thread per gestire operazioni di lunga durata. E invece di Runnablete puoi usare Callable, che restituisce un risultato. Il risultato è incapsulato in un Future<ReturnType>oggetto, quindi puoi ottenerlo quando è tornato.

Ecco una descrizione di come potrebbe apparire un'API jdbc non bloccante da Oracle presentata a JavaOne: https://static.rainfocus.com/oracle/oow16/sess/1461693351182001EmRq/ppt/CONF1578%2020160916.pdf

Quindi sembra che alla fine saranno davvero possibili chiamate JDBC veramente asincrone.

Un'idea folle: potresti usare un modello Iteratee sul risultato JBDC Impostato in un po 'di Future / Promise

Hammersmith lo fa per MongoDB .

Sto solo pensando idee qui. Perché non è possibile avere un pool di connessioni al database con ognuna con un thread. Ogni thread ha accesso a una coda. Quando vuoi fare una query che richiede molto tempo, puoi mettere in coda e poi uno dei thread lo raccoglierà e lo gestirà. Non avrai mai troppi thread perché il numero dei thread è limitato.

Modifica: o meglio ancora, solo un numero di thread. Quando un thread vede qualcosa in una coda, chiede una connessione dal pool e lo gestisce.

La libreria commons-dbutils ha il supporto per un AsyncQueryRunneroggetto da te fornito ExecutorServicee restituisce a Future. Vale la pena dare un'occhiata perché è semplice da usare e assicurati di non perdere risorse.

Se sei interessato alle API di database asincrone per Java, dovresti sapere che esiste una nuova iniziativa per creare un set di API standard basate su CompletableFuture e lambdas. Esiste anche un'implementazione di queste API su JDBC che può essere utilizzata per esercitarsi con queste API: https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ JavaDoc è menzionato nel README di il progetto github.