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 :

• Script-based : les demandes sont effectuées à l'aide de chaînes Gremlin basées sur du texte, comme ceci :

  • Avec le pilote Java et Client.submit(string).

  • Avec la console Gremlin et :remote connect.

  • Avec l'API HTTP.

• Bytecode-based : les demandes sont effectuées à l'aide du bytecode Gremlin sérialisé typique des variantes du langage Gremlin (GLV).

  Par exemple, avec le pilote Java, g = traversal().withRemote(...).

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.

Note

Les transactions Gremlin doivent toujours être validées ou annulées, afin que les ressources côté serveur puissent être libérées.

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 le bytecode, après TinkerPop 3.5.x, 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 syntaxe tx() en Python, Javascript et .NET.

Avertissement

Les requêtes en lecture seule sans session sont exécutées sous un isolement SNAPSHOT, mais les requêtes en lecture seule exécutées dans le cadre d'une transaction explicite sont exécutées sous un isolement SERIALIZABLE. Les requêtes en lecture seule exécutées sous un isolement SERIALIZABLE entraînent une surcharge plus importante et peuvent bloquer les écritures simultanées ou être bloquées par ces dernières, contrairement à celles exécutées sous un isolement SNAPSHOT.