Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Transactions Gremlin dans Neptune

Il existe plusieurs contextes dans lesquels les transactions Gremlin sont exécutées. Lorsque vous travaillez avec Gremlin, il est important de comprendre le contexte dans lequel vous évoluez et quelles en sont les implications :

Pour l'un ou l'autre des contextes ci-dessus, il existe un contexte supplémentaire dans lequel la demande est envoyée sans session ou liée à une session.

Demandes sans session

En l'absence de session, une demande équivaut à une transaction unique.

Pour les scripts, cela implique qu'une ou plusieurs déclarations Gremlin envoyées dans le cadre d'une seule demande sont validées ou annulées en tant que transaction unique. Par exemple :

Cluster cluster = Cluster.open();
Client client = cluster.connect(); // sessionless
// 3 vertex additions in one request/transaction:
client.submit("g.addV();g.addV();g.addV()").all().get();

Pour le bytecode, une demande sans session est effectuée pour chaque traversée générée et exécutée à partir de g :

GraphTraversalSource g = traversal().withRemote(...);

// 3 vertex additions in three individual requests/transactions:
g.addV().iterate();
g.addV().iterate();
g.addV().iterate();

// 3 vertex additions in one single request/transaction:
g.addV().addV().addV().iterate();

Demandes liées à une session

Lorsqu'elles sont liées à une session, plusieurs demandes peuvent être appliquées dans le contexte d'une seule transaction.

Pour les scripts, cela implique qu'il n'est pas nécessaire de concaténer toutes les opérations du graphe en une seule valeur de chaîne intégrée :

Cluster cluster = Cluster.open();
Client client = cluster.connect(sessionName); // session
try {
    // 3 vertex additions in one request/transaction:
    client.submit("g.addV();g.addV();g.addV()").all().get();
} finally {
    client.close();
}

try {
    // 3 vertex additions in three requests, but one transaction:
    client.submit("g.addV()").all().get(); // starts a new transaction with the same sessionName
    client.submit("g.addV()").all().get();
    client.submit("g.addV()").all().get();
} finally {
    client.close();
}

Pour les sessions basées sur des scripts, la fermeture du client client.close() valide la transaction. Aucune commande de restauration explicite n'est disponible dans les sessions basées sur des scripts. Pour forcer une annulation, vous pouvez provoquer l'échec de la transaction en émettant une requête, par exemple g.inject(0).fail('rollback') avant de fermer le client.

Pour le bytecode, la transaction peut être contrôlée de manière explicite et la session gérée de manière transparente. Les variantes du langage Gremlin (GLV) prennent en charge la syntaxe tx() de Gremlin pour effectuer des opérations de type commit() ou rollback() d'une transaction, comme suit :

GraphTraversalSource g = traversal().withRemote(conn);

Transaction tx = g.tx();

// Spawn a GraphTraversalSource from the Transaction.
// Traversals spawned from gtx are executed within a single transaction.
GraphTraversalSource gtx = tx.begin();
try {
    gtx.addV('person').iterate();
    gtx.addV('software').iterate();

    tx.commit();
} finally {
    if (tx.isOpen()) {
        tx.rollback();
    }
}

Bien que l'exemple ci-dessus soit écrit en Java, vous pouvez également utiliser cette tx() syntaxe dans d'autres langages. Pour connaître la syntaxe des transactions spécifique au langage, consultez la section Transactions de la TinkerPop documentation Apache pour Java, Python, Javascript, .NET et Go.

Comportement du délai d'expiration pour la validation et l'annulation du bytecode

Lorsque vous utilisez des transactions basées sur un bytecode avec la tx() syntaxe, les rollback() opérations commit() et ne sont pas soumises aux paramètres de délai d'expiration des requêtes. Ni le neptune_query_timeout paramètre global ni les valeurs de délai d'expiration par requête définis ne evaluationTimeout s'appliquent à ces opérations. Sur le serveur, commit() et rollback() exécutez-les sans limite de temps jusqu'à ce qu'ils soient terminés ou qu'ils rencontrent une erreur.

Du côté client, les tx.rollback() appels tx.commit() et les appels du pilote G705 ne seront pas terminés tant que le serveur ne répondra pas. Selon la langue, cela peut se manifester sous la forme d'un appel bloquant ou d'une opération asynchrone non résolue. Aucun pilote ne fournit de paramètre de délai d'expiration intégré qui limite ces appels. Consultez la documentation de l'API correspondant à votre variante de langage G705 spécifique pour plus de détails sur le comportement simultané associé à ces fonctionnalités de transaction.

Si vous devez limiter le temps d'attente de votre application pour un commit() ourollback(), vous pouvez utiliser les fonctionnalités de simultanéité de votre langue pour appliquer un délai d'attente côté client. Si le délai d'attente côté client se déclenche, le serveur poursuit le traitement de l'opération. L'opération côté serveur maintient un thread de travail jusqu'à ce qu'il soit terminé. Après un délai d'attente côté client, fermez la connexion et créez-en une nouvelle plutôt que de réutiliser la connexion existante, car l'état de la transaction est indéterminé.

Nettoyage des transactions côté serveur

Si un client déconnecte ou abandonne une transaction sans la valider ou l'annuler, Neptune dispose de mécanismes côté serveur qui finissent par nettoyer la transaction orpheline :

Ces mécanismes de nettoyage sont des filets de sécurité. Nous vous recommandons de toujours valider ou annuler explicitement les transactions lorsque vous en avez terminé avec elles.