Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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:

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

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. Beispiel:

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 skriptbasierten Sitzungen wird die Transaktion festgeschrieben, wenn der Client mit client.close() geschlossen wird. In skriptbasierten Sitzungen ist kein expliziter Rollback-Befehl verfügbar. Um ein Rollback zu erzwingen, können Sie die Transaktion zum Scheitern bringen, indem Sie beispielsweise g.inject(0).fail('rollback') vor dem Schließen des Clients eine Abfrage stellen.

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

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 anderen Sprachen verwenden. Informationen zur sprachspezifischen Transaktionssyntax finden Sie im Abschnitt Transaktionen der TinkerPop Apache-Dokumentation für Java, Python, Javascript , .NET und Go.

Timeout-Verhalten für Bytecode-Commit und -Rollback

Wenn Sie Bytecode-basierte Transaktionen mit der tx() Syntax verwenden, unterliegen die rollback() Operationen commit() und keinen Abfrage-Timeout-Einstellungen. Weder der globale neptune_query_timeout Parameter noch die durch festgelegten Timeout-Werte pro Abfrage gelten für diese Operationen. evaluationTimeout Auf dem Server commit() und ohne Zeitlimit rollback() ausgeführt, bis sie abgeschlossen sind oder ein Fehler auftritt.

Auf der Client-Seite werden die tx.rollback() Aufrufe des Gremlin-Treibers tx.commit() und des Gremlin-Treibers erst abgeschlossen, wenn der Server reagiert. Je nach Sprache kann sich dies als blockierender Anruf oder als ungelöster asynchroner Vorgang äußern. Kein Treiber bietet eine integrierte Timeout-Einstellung, die diese Aufrufe begrenzt. Einzelheiten zum Parallelitätsverhalten im Zusammenhang mit diesen Transaktionsfunktionen finden Sie in der API-Dokumentation für Ihre spezifische Gremlin-Sprachvariante.

Wenn Sie die Zeit, die Ihre Anwendung auf ein commit() oder wartet, einschränken müssenrollback(), können Sie die Parallelitätsfunktionen Ihrer Sprache verwenden, um einen clientseitigen Timeout anzuwenden. Wenn der clientseitige Timeout ausgelöst wird, setzt der Server die Verarbeitung des Vorgangs fort. Der serverseitige Vorgang enthält einen Worker-Thread, bis er abgeschlossen ist. Schließen Sie nach einem clientseitigen Timeout die Verbindung und erstellen Sie eine neue, anstatt die bestehende Verbindung wiederzuverwenden, da der Transaktionsstatus unbestimmt ist.

Server-side Bereinigung der Transaktion

Wenn ein Client eine Transaktion trennt oder abbricht, ohne sie festzuschreiben oder rückgängig zu machen, verfügt Neptune über serverseitige Mechanismen, die die verwaiste Transaktion schließlich bereinigen:

Bei diesen Reinigungsmechanismen handelt es sich um Sicherheitsnetze. Wir empfehlen, dass Sie Transaktionen immer explizit festschreiben oder rückgängig machen, wenn Sie mit ihnen fertig sind.