Comprendre la gestion des sessions avec le chauffeur sur Amazon QLDB

Important

Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez Migrer un Amazon QLDB Ledger vers Amazon Aurora SQL Postgre.

Si vous avez déjà utilisé un système de gestion de base de données relationnelle (RDBMS), vous connaissez peut-être les connexions simultanées. QLDBn'a pas le même concept qu'une RDBMS connexion traditionnelle car les transactions sont exécutées avec des messages de HTTP demande et de réponse.

DansQLDB, le concept analogue est une session active. Une session est conceptuellement similaire à une connexion utilisateur : elle gère les informations relatives à vos demandes de transaction de données adressées à un registre. Une session active est une session qui exécute activement une transaction. Il peut également s'agir d'une session ayant récemment terminé une transaction au cours de laquelle le service prévoit de commencer immédiatement une autre transaction. QLDBprend en charge une transaction active par session.

La limite de sessions actives simultanées par registre est définie dansQuotas et limites sur Amazon QLDB. Une fois cette limite atteinte, toute session qui tente de démarrer une transaction entraîne une erreur (LimitExceededException).

Pour connaître les meilleures pratiques relatives à la configuration d'un pool de sessions dans votre application à l'aide du QLDB pilote, consultez Configuration de l' QldbDriver objet les recommandations relatives aux QLDB pilotes Amazon.

Table des matières

• Cycle de vie des sessions
• Expiration de session
• Gestion des sessions dans le QLDB driver
  • Vue d'ensemble du regroupement de sessions
  • Regroupement de sessions et logique de transaction
  • Retourner les sessions à la piscine

Cycle de vie des sessions

La séquence d'APIopérations de QLDBsession suivante représente le cycle de vie typique d'une QLDB session :

1. StartSession

2. StartTransaction

3. ExecuteStatement

4. CommitTransaction

5. Répétez les étapes 2 à 4 pour démarrer d'autres transactions (une transaction à la fois).

6. EndSession

Expiration de session

QLDBexpire et annule une session après une durée de vie totale de 13 à 17 minutes, qu'une transaction soit en cours d'exécution active ou non. Les sessions peuvent être perdues ou perturbées pour un certain nombre de raisons, telles qu'une panne matérielle, une défaillance du réseau ou le redémarrage d'applications. QLDBimpose une durée de vie maximale aux sessions afin de garantir la résilience de l'application cliente en cas d'échec de session.

Gestion des sessions dans le QLDB driver

Bien que vous puissiez utiliser an AWS SDK pour interagir directement avec la QLDBsessionAPI, cela ajoute de la complexité et vous oblige à calculer un résumé de validation. QLDButilise ce condensé de validation pour garantir l'intégrité des transactions. Au lieu d'interagir directement avec celui-ciAPI, nous vous recommandons d'utiliser le QLDB pilote.

Le pilote fournit une couche d'abstraction de haut niveau au-dessus des données API transactionnelles. Il rationalise le processus d'exécution des instructions partiQL sur les données du registre en gérant les appels. SendCommandAPI Ces API appels nécessitent plusieurs paramètres que le pilote gère pour vous, notamment la gestion des sessions, des transactions et la politique de relance en cas d'erreur.

Rubriques

• Vue d'ensemble du regroupement de sessions
• Regroupement de sessions et logique de transaction
• Retourner les sessions à la piscine

Vue d'ensemble du regroupement de sessions

Dans les anciennes versions du QLDB pilote (par exemple, Java v1.1.0), nous fournissions deux implémentations de l'objet pilote : une version standard, une version non QldbDriver groupée et une. PooledQldbDriver Comme son nom l'indique, il PooledQldbDriver gère un pool de sessions qui sont réutilisées dans les transactions.

Sur la base des commentaires des utilisateurs, les développeurs préfèrent utiliser la fonctionnalité de mise en commun et ses avantages par défaut, plutôt que d'utiliser le pilote standard. Nous avons donc supprimé PooledQldbDriver et déplacé la fonctionnalité de regroupement de sessions vers. QldbDriver Cette modification est incluse dans la dernière version de chaque pilote (par exemple, Java v2.0.0).

Le pilote fournit trois niveaux d'abstractions :

• Pilote (implémentation de pilotes groupés) — L'abstraction de niveau supérieur. Le pilote gère et gère un pool de sessions. Lorsque vous demandez au pilote d'exécuter une transaction, le pilote choisit une session dans le pool et l'utilise pour exécuter la transaction. Si la transaction échoue en raison d'une erreur de session (InvalidSessionException), le pilote utilise une autre session pour réessayer la transaction. Essentiellement, le pilote offre une expérience de session entièrement gérée.

• Session — Un niveau en dessous de l'abstraction du pilote. Une session est contenue dans un pool et le pilote gère le cycle de vie de la session. Si une transaction échoue, le pilote réessaie jusqu'à un certain nombre de tentatives au cours de la même session. Mais si la session rencontre une erreur (InvalidSessionException), la QLDB supprime en interne. Le pilote est alors chargé d'obtenir une autre session du pool pour réessayer la transaction.

• Transaction : niveau d'abstraction le plus bas. Une transaction est contenue dans une session, qui gère le cycle de vie de la transaction. La session est chargée de réessayer la transaction en cas d'erreur. La session garantit également qu'elle ne divulgue pas une transaction ouverte qui n'a pas été validée ou annulée.

Dans la dernière version de chaque pilote, vous pouvez effectuer des opérations au niveau de l'abstraction du pilote uniquement. Vous n'avez aucun contrôle direct sur les sessions et transactions individuelles (c'est-à-dire qu'aucune API opération ne permet de démarrer manuellement une nouvelle session ou transaction).

Regroupement de sessions et logique de transaction

La dernière version de chaque pilote ne fournit plus d'implémentation non groupée de l'objet pilote. Par défaut, l'QldbDriverobjet gère le pool de sessions. Lorsque vous passez un appel pour exécuter une transaction, le chauffeur effectue les étapes suivantes :

1. Le conducteur vérifie s'il a atteint la limite du pool de sessions. Dans ce cas, le pilote lance immédiatement une NoSessionAvailable exception. Dans le cas contraire, il passe à l'étape suivante.

2. Le pilote vérifie si une session est disponible dans le pool.

   • Si une session est disponible dans le pool, le pilote l'utilise pour exécuter une transaction.

   • Si aucune session n'est disponible dans le pool, le pilote crée une nouvelle session et l'utilise pour exécuter une transaction.

3. Une fois que le pilote a obtenu une session à l'étape 2, il lance l'executeopération sur l'instance de session.

4. Pendant le execute fonctionnement de la session, le conducteur essaie de démarrer une transaction en appelantstartTransaction.

   • Si la session n'est pas valide, l'startTransactionappel échoue et le pilote revient à l'étape 1.

   • Si l'startTransactionappel aboutit, le conducteur passe à l'étape suivante.

5. Le pilote exécute votre expression lambda. Cette expression lambda peut contenir un ou plusieurs appels pour exécuter des instructions partiQL. Une fois que l'expression lambda a fini de s'exécuter sans aucune erreur, le pilote procède à la validation de la transaction.

6. La validation de la transaction peut avoir l'un des deux résultats suivants :

   • La validation réussit et le pilote redonne le contrôle au code de votre application.

   • La validation échoue en raison d'un conflit optimiste avec le contrôle de simultanéité (OCC). Dans ce cas, le pilote réessaie les étapes 4 à 6 en utilisant la même session. Le nombre maximal de tentatives est configurable dans le code de votre application. La limite par défaut est de4.

Note

Si un appel InvalidSessionException est lancé au cours des étapes 4 à 6, le pilote marque la session comme étant fermée et revient à l'étape 1 pour réessayer la transaction.

Si une autre exception est émise au cours des étapes 4 à 6, le pilote vérifie si l'exception peut être réessayée. Si tel est le cas, il réessaie la transaction jusqu'au nombre de tentatives spécifié. Si ce n'est pas le cas, il propage (fait des bulles et lance) l'exception dans le code de votre application.

Retourner les sessions à la piscine

Si un InvalidSessionException événement se produit à tout moment au cours d'une transaction active, le pilote ne renvoie pas la session au pool. QLDBsupprime la session à la place, et le pilote obtient une autre session du pool. Dans tous les autres cas, le pilote renvoie la session au pool.