Transactions Gremlin à Neptune

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

• Script-based— Les requêtes sont effectuées à l'aide de chaînes Gremlin basées sur du texte, comme ceci :

  • À l'aide du pilote Java etClient.submit(string).

  • À l'aide de la console Gremlin et. :remote connect

  • Utilisation de l'API HTTP.

• Bytecode-based— Les requêtes sont effectuées à l'aide du bytecode Gremlin sérialisé typique des variantes du langage Gremlin (GLV).

  Par exemple, à l'aide du pilote Java,g = traversal().withRemote(...).

Pour l'un ou l'autre des contextes ci-dessus, il existe le contexte supplémentaire de l'envoi de la demande 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 seule transaction.

Pour les scripts, cela implique qu'une ou plusieurs instructions Gremlin envoyées dans le cadre d'une seule requête seront 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 requête sans session est faite 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 incorporé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 TinkerPop3.5.x, la transaction peut ensuite ê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 tx() syntaxe de Gremlin commit() ou rollback() 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 Python, Javascript et .NET.

Avertissement

Les requêtes en lecture seule sans session sont exécutées sous isolation SNAPSHOT, tandis que les requêtes en lecture seule exécutées dans le cadre d'une transaction explicite sont exécutées sous isolation SERIALIZABLE. Les requêtes en lecture seule exécutées de SERIALIZABLE manière isolée entraînent des frais supplémentaires et peuvent être bloquées ou bloquées par des écritures simultanées, contrairement à celles exécutées de manière isolée. SNAPSHOT