Gremlin-Transaktionen in Neptune

Es gibt verschiedene Kontexte, in denen Gremlin-Transaktionen ausgeführt werden. Bei der Arbeit mit Gremlin ist es wichtig, den Kontext, in dem Sie arbeiten, und dessen Auswirkungen zu verstehen:

• Script-based   –   Anforderungen werden mit textbasierten Gremlin-Zeichenfolgen gesendet, z. B.:

  • Verwenden von Java-Treiber und Client.submit(string).

  • Verwenden von Gremlin-Konsole und :remote connect.

  • Mit dem HTTPAPI.

• Bytecode-based— Anfragen werden mit serialisiertem Gremlin-Bytecode gestellt, der für Gremlin-Sprachvarianten () typisch ist. GLV

  Zum Beispiel mit dem Java-Treiber, g = traversal().withRemote(...).

Für jeden der oben genannten Kontexte gibt es zusätzlichen Kontext – ob die Anforderung als sitzungslos oder sitzungsgebunden gesendet wird.

Anmerkung

Für Gremlin-Transaktionen muss stets entweder ein Commit oder ein Rollback ausgeführt werden, damit serverseitige Ressourcen freigegeben werden können.

Anforderungen, die nicht an eine Sitzung gebunden sind

Wenn eine Anforderung sitzungslos ist, entspricht eine Anforderung einer einzelnen Transaktion.

Im Fall von Skripts bedeutet dies, dass eine oder mehrere Gremlin-Anweisungen, die in einer einzelnen Anforderung gesendet werden, das Commit oder Rollback als einzelne Transaktion ausführen. Beispielsweise:

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();

Im Fall von Bytecode wird für jede Traversierung, die über g ausgelöst und ausgeführt wird, eine sitzungslose Anforderung gesendet.

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();

Anforderungen, die an eine Sitzung gebunden sind

Wenn Anforderungen an eine Sitzung gebunden sind, können mehrere Anforderungen im Kontext einer einzelnen Transaktion gesendet werden.

Im Fall von Skripts bedeutet dies, dass Diagrammoperationen nicht alle zu einem einzelnen eingebetteten Zeichenfolgenwert verkettet werden müssen:

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();
}

Bei Bytecode kann danach die Transaktion explizit gesteuert TinkerPop 3.5.x und die Sitzung transparent verwaltet werden. Gremlin Language Variants (GLV) unterstützen die tx() Gremlin-Syntax für eine Transaktion wie folgt: commit() rollback()

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();
    }
}

Obwohl das obige Beispiel in Java geschrieben ist, können Sie diese tx() Syntax auch in Python, Javascript und verwenden. NET.

Warnung

Sitzungslose schreibgeschützte Abfragen werden SNAPSHOTisoliert ausgeführt, aber schreibgeschützte Abfragen, die innerhalb einer expliziten Transaktion ausgeführt werden, werden isoliert ausgeführt. SERIALIZABLE Die schreibgeschützten Abfragen unter SERIALIZABLE-Isolation führen zu einem höheren Overhead und können im Gegensatz zu isolierten Abfragen unter SNAPSHOT gleichzeitige Schreibvorgänge blockieren oder von diesen blockiert werden.