Come possiamo utilizzare il pooling di connessioni JDBC con AWS Lambda?

Question

È possibile utilizzare il pooling di connessioni JDBC con AWS Lambda? La funzione lambda AS AWS viene chiamata su un evento specifico, quindi la sua durata persiste anche dopo aver terminato una delle sue chiamate?

Answer 1

Sì, il lambda è per lo più persistente, quindi il pool di connessioni JDBC dovrebbe funzionare. La prima volta che viene richiamata una funzione lambda, l'ambiente verrà creato e potrebbe essere riutilizzato o meno. Ma in pratica, le successive invocazioni spesso riutilizzano lo stesso processo lambda insieme a tutto lo stato del programma se gli eventi di attivazione si verificano spesso.

Questo breve funzione lambda dimostra questo:

package test; 

import com.amazonaws.services.lambda.runtime.Context; 
import com.amazonaws.services.lambda.runtime.RequestHandler; 

public class TestLambda implements RequestHandler<String, String> { 

    private int invocations = 0; 

    public String handleRequest(String request, Context context) { 
     invocations++; 
     System.out.println("invocations = " + invocations); 
     return request; 
    } 
} 

richiamare questo dalla console AWS con qualsiasi stringa come l'evento di prova. Nei registri di CloudWatch, vedrai il numero di invocazioni incrementare ogni volta.

Answer 2

No. Tecnicamente, è possibile creare un pool di connessioni al di fuori della funzione del gestore ma poiché è possibile utilizzare una singola connessione per invocazione, tutto ciò che si sta facendo è vincolare le connessioni del database e allocare un pool di cui puoi usare sempre 1.

Dopo aver caricato la funzione Lambda in AWS, la prima volta che viene richiamata AWS crea un contenitore ed esegue il codice di installazione (il codice al di fuori della funzione del gestore che crea il pool - diciamo N connessioni) prima di richiamare il codice del gestore.

Quando arriva la richiesta successiva, AWS può riutilizzare il contenitore (o non farlo. Di solito lo fa, ma questo è giù per AWS e non sotto il tuo controllo).

Supponendo che riutilizza il contenitore, la vostra funzione di gestione verrà richiamato (il codice di impostazione sarà non essere eseguito di nuovo) e la funzione sarebbe utilizzare uno di N delle connessioni al database dalla piscina (tenuto al livello di contenitore). Questa è probabilmente la prima connessione dal pool, numero 1 poiché è garantito che non sia in uso, poiché è impossibile che due funzioni vengano eseguite contemporaneamente nello stesso contenitore. Continua a leggere per una spiegazione.

Se AWS non riutilizza il contenitore, creerà un nuovo contenitore e il codice assegnerà un altro pool di connessioni N. A seconda del volume dei contenitori, è possibile esaurire completamente il pool di database.

Se due richieste arrivano contemporaneamente, AWS non può richiamare lo stesso gestore allo stesso tempo. Se ciò fosse possibile, avresti un problema di stato condiviso con le variabili definite a livello di ambito del contenitore. Invece, AWS utilizzerà due contenitori separati e questi entrambi assegneranno un pool di connessioni N ciascuna, cioè 2N connessioni al database.

Non è mai necessario che una singola funzione di chiamata richieda più di una connessione (a meno che, naturalmente, non sia necessario comunicare con due database indipendenti nello stesso contesto).

L'unica volta che un pool di connessioni sarebbe utile è se si trovasse a un livello sopra l'ambito del contenitore, ovvero, trasmesso dall'ambiente AWS stesso al contenitore. Non è possibile.

Il caso migliore che si possa sperare è avere una connessione singola per container. Anche in questo caso, è necessario gestire questa singola connessione per assicurarsi che il server del database non si sia disconnesso o riavviato. Se lo fa, la connessione del tuo contenitore morirà e il tuo gestore non sarà più in grado di connettersi di nuovo (finché il contenitore non muore), a meno che tu non scriva del codice nella tua funzione per verificare la presenza di connessioni interrotte.Su un server occupato, il contenitore potrebbe impiegare molto tempo a morire.

Inoltre, tenere presente che se la funzione del gestore non riesce, ad esempio a metà della transazione o dopo aver bloccato una tabella, la successiva richiesta di richiesta otterrà lo stato di connessione dirty dal contenitore. La prima invocazione potrebbe aver aperto una transazione e morì. La seconda invocazione può commettere e includere tutte le query precedenti fino all'insuccesso.

Si consiglia di non gestire lo stato al di fuori della funzione di gestione, a meno che non si abbia una necessità specifica di ottimizzazione. Se lo fai, quindi utilizzare una singola connessione, non un pool.