Comprensione della gestione delle sessioni con il driver in Amazon QLDB - Database Amazon Quantum Ledger (Amazon QLDB)

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Comprensione della gestione delle sessioni con il driver in Amazon QLDB

Se hai esperienza nell'uso di un sistema di gestione di database relazionali (RDBMS, Relational Database Management System), potresti avere familiarità con le connessioni simultanee. QLDB non ha lo stesso concetto di connessione RDBMS tradizionale perché le transazioni vengono eseguite con messaggi di richiesta e risposta HTTP.

In QLDB, il concetto analogo è una sessione attiva. Una sessione è concettualmente simile all'accesso di un utente: gestisce le informazioni sulle richieste di transazioni di dati inviate a un registro. Una sessione attiva è una sessione che esegue attivamente una transazione. Può anche trattarsi di una sessione che ha recentemente concluso una transazione in cui il servizio prevede che avvierà immediatamente un'altra transazione. QLDB supporta una transazione in esecuzione attiva per sessione.

Il limite di sessioni attive simultanee per libro mastro è definito inQuote e limiti in Amazon QLDB. Una volta raggiunto questo limite, qualsiasi sessione che tenti di avviare una transazione genererà un errore (LimitExceededException).

Per le best practice per la configurazione di un pool di sessioni nell'applicazione utilizzando il driver QLDB, consulta iConfigurazione della QldbDriver oggetto consigli sui driver di Amazon QLDB.

Ciclo di vita di una sessione

La seguente sequenza di operazioni dell'API QLDB Session rappresenta il ciclo di vita tipico di una sessione QLDB:

  1. StartSession

  2. StartTransaction

  3. ExecuteStatement

  4. CommitTransaction

  5. Ripeti i passaggi da 2 a 4 per avviare più transazioni (una transazione alla volta).

  6. EndSession

Scadenza della sessione

QLDB scade e scarta una sessione dopo una durata totale di 13-17 minuti, indipendentemente dal fatto che stia eseguendo attivamente una transazione. Le sessioni possono essere perse o compromesse per diversi motivi, ad esempio guasti hardware, errori di rete o riavvii delle applicazioni. QLDB impone una durata massima delle sessioni per garantire che l'applicazione client sia resiliente agli errori della sessione.

Gestione delle sessioni nel driver QLDB

Sebbene sia possibile utilizzare unAWS SDK per interagire direttamente con l'API di sessione QLDB, ciò aggiunge complessità e richiede il calcolo di un commit digest. QLDB utilizza questo commit digest per garantire l'integrità delle transazioni. Invece di interagire direttamente con questa API, consigliamo di utilizzare il driver QLDB.

Il driver fornisce un livello di astrazione di alto livello sopra l'API dei dati transazionali. Semplifica il processo di esecuzione delle istruzioni PartiQL sui dati contabili gestendo le chiamate SendCommandAPI. Queste chiamate API richiedono diversi parametri che il driver gestisce per te, tra cui la gestione delle sessioni, delle transazioni e la politica di riprova in caso di errori.

Panoramica del pool di sessioni

Nelle versioni precedenti del driver QLDB (ad esempio, Java v1.1.0), abbiamo fornito due implementazioni dell'oggetto driver: una standard, non in poolQldbDriver e unaPooledQldbDriver. Come suggerisce il nome,PooledQldbDriver mantiene un pool di sessioni che vengono riutilizzate tra le transazioni.

In base al feedback degli utenti, gli sviluppatori preferiscono utilizzare la funzionalità di pooling e i relativi vantaggi come impostazione predefinita, anziché utilizzare il driver standard. Quindi, abbiamo rimossoPooledQldbDriver e spostato la funzionalità di pooling delle sessioni suQldbDriver. Questa modifica è inclusa nell'ultima versione di ogni driver (ad esempio, Java v2.0.0).

Il driver offre tre livelli di astrazioni:

  • Driver (implementazione del driver in pool): l'astrazione di primo livello. Il conducente gestisce e gestisce un pool di sessioni. Quando si chiede al conducente di eseguire una transazione, il conducente sceglie una sessione dal pool e la utilizza per eseguire la transazione. Se la transazione fallisce a causa di un errore di sessione (InvalidSessionException), il driver utilizza un'altra sessione per riprovare la transazione. In sostanza, il conducente offre un'esperienza di sessione completamente gestita.

  • Sessione: un livello al di sotto dell'astrazione del driver. Una sessione è contenuta in un pool e il driver gestisce il ciclo di vita della sessione. Se una transazione fallisce, il driver la riprova fino a un numero specificato di tentativi utilizzando la stessa sessione. Ma se la sessione incontra un errore (InvalidSessionException), QLDB lo scarta internamente. Il conducente è quindi responsabile di ottenere un'altra sessione dal pool per riprovare la transazione.

  • Transazione: il livello di astrazione più basso. Una transazione è contenuta in una sessione e la sessione gestisce il ciclo di vita della transazione. La sessione è responsabile del nuovo tentativo della transazione in caso di errore. La sessione garantisce inoltre che non venga divulgata una transazione aperta che non è stata confermata o annullata.

Nella versione più recente di ogni driver, è possibile eseguire operazioni solo a livello di driver di astrazione. Non hai il controllo diretto sulle singole sessioni e transazioni (ovvero, non ci sono operazioni API per avviare manualmente una nuova sessione o transazione).

Raggruppamento delle sessioni e logica delle transazioni

L'ultima versione di ogni driver non fornisce più un'implementazione non condivisa dell'oggetto driver. Per impostazione predefinita, l'QldbDriveroggetto gestisce il pool di sessioni. Quando si effettua una chiamata per eseguire una transazione, il conducente effettua le seguenti operazioni:

  1. Il conducente verifica se ha raggiunto il limite del pool di sessioni. In tal caso, il conducente genera immediatamente un'NoSessionAvailableeccezione. Altrimenti, passa alla fase successiva.

  2. Il driver verifica se il pool dispone di una sessione disponibile.

    • Se nel pool è disponibile una sessione, il driver la utilizza per eseguire una transazione.

    • Se nel pool non è disponibile alcuna sessione, il driver crea una nuova sessione e la utilizza per eseguire una transazione.

  3. Dopo aver ottenuto una sessione nel passaggio 2, il driver richiama l'executeoperazione sull'istanza della sessione.

  4. Durante ilexecute funzionamento della sessione, il conducente tenta di avviare una transazione chiamandostartTransaction.

    • Se la sessione non è valida, lastartTransaction chiamata fallisce e il conducente torna al passaggio 1.

    • Se lastartTransaction chiamata ha esito positivo, il conducente passa alla fase successiva.

  5. Il conducente esegue la tua espressione lambda. Questa espressione lambda può contenere una o più chiamate per eseguire istruzioni PartiQL. Dopo che l'espressione lambda termina l'esecuzione senza errori, il driver procede al salvataggio della transazione.

  6. L'esecuzione della transazione può avere uno dei due risultati:

    • Il commit ha esito positivo e il driver restituisce il controllo al codice dell'applicazione.

    • Il commit fallisce a causa di un conflitto ottimistico per il controllo della concorrenza (OCC). In questo caso, il conducente riprova i passaggi da 4 a 6 utilizzando la stessa sessione. Il numero massimo di tentativi di ripetizione è configurabile nel codice dell'applicazione. Il limite predefinito è4.

Nota

SeInvalidSessionException viene generato un durante i passaggi da 4 a 6, il driver contrassegna la sessione come chiusa e torna al passaggio 1 per riprovare la transazione.

Se viene generata un'altra eccezione durante i passaggi da 4 a 6, il conducente verifica se l'eccezione può essere ritentata. In tal caso, riprova la transazione fino al numero specificato di tentativi. In caso contrario, propaga (si riempie di bolle e genera) l'eccezione al codice dell'applicazione.

Restituzione delle sessioni in piscina

SeInvalidSessionException si verifica un errore in qualsiasi momento nel corso di una transazione attiva, il conducente non riporta la sessione al pool. QLDB scarta invece la sessione e il driver ottiene un'altra sessione dal pool. In tutti gli altri casi, il driver riporta la sessione nel pool.