È bello inserire le operazioni jdbc negli attori?

Question

Sto costruendo una webapp tradizionale che esegue operazioni CRUD di database tramite JDBC. E mi chiedo se sia opportuno inserire le operazioni jdbc in attori, fuori dal thread di elaborazione della richiesta corrente. Ho fatto qualche ricerca ma non ho trovato tutorial o applicazioni di esempio che dimostrassero questo.

Quindi, quali sono i pro e i pro? Questa asinconizzazione migliorerà la capacità dell'appserver (vale a dire la richiesta concorrente elaborata) come nio?

Answer 1

Se mettere l'accesso JDBC negli attori è "buono" o non dipende molto dal resto dell'applicazione.

La maggior parte delle applicazioni Web oggi sono sincrone, grazie allo Servlet API che è alla base della maggior parte dei framework web Java (e Scala). Mentre ora stiamo vedendo support for asynchronous servlets, quel supporto non ha funzionato su tutti i framework. A meno che non inizi con a framework that supports asynchronous processing, l'elaborazione della richiesta sarà sincrona.

Per quanto riguarda JDBC, JDBC is synchronous. Realisticamente non ci sarà mai niente da fare a riguardo, visto l'onere che si avrebbe a modificare le implementazioni dei driver JDBC di gazillion che sono fuori nel mondo. Possiamo sperare, ma non trattenere il respiro.

E le stesse implementazioni JDBC non devono essere thread-safe, quindi richiamare un'operazione su una connessione JDBC prima del completamento di qualche altra operazione sulla stessa connessione comporterà un comportamento indefinito. E comportamento indefinito! = Buono.

Quindi la mia ipotesi è che non vedrete gli stessi miglioramenti di capacità che vedete con NIO.

Edit: appena scoperto adbcj; un'API driver di database asincrono. È un progetto sperimentale scritto per una tesi di master, molto presto, sperimentale. È un esperimento degno, e spero che abbia successo. Controlla!

Ma, se si sta costruendo un asincrono, sistema di attore-based, mi piace molto l'idea di avere accesso ai dati o attori repository, molto nello stesso modo in cui il avrei data acccess o repository oggetti in un strati OO architettura.

Gli attori garantiscono che i messaggi vengano elaborati uno alla volta, il che è ideale per accedere a una singola connessione JDBC. (Una parola di cautela: la maggior parte dei pool di connessioni è impostata per distribuire la connessione per thread, che non funziona bene con gli attori, ma è necessario assicurarsi che si stia utilizzando una connessione per attore. per la gestione delle transazioni.)

Ciò consente di trattare il database come il sistema remoto asincrono che dovremmo averlo trattato per tutto il tempo. Ciò significa anche che i risultati degli attori di accesso/repository dati sono futures, che sono composable. Ciò semplifica il coordinamento dell'accesso ai dati con altre attività asincrone.

Quindi, è buono? Probabilmente, se si adatta all'architettura del resto del tuo sistema. Migliorerà la capacità? Ciò dipenderà dal tuo sistema generale, ma suona come un esperimento molto degno.