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 beim Schließen des Clients mit die Transaktion festgeschriebenclient.close(). In skriptbasierten Sitzungen ist kein expliziter Rollback-Befehl verfügbar. Um ein Rollback zu erzwingen, können Sie dafür sorgen, dass die Transaktion fehlschlägt, indem Sie beispielsweise g.inject(0).fail('rollback') vor dem Schließen des Clients eine Abfrage ausgeben.

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. Eine sprachspezifische Transaktionssyntax finden Sie im Abschnitt Transaktionen der TinkerPop Apache-Dokumentation für Java, Python, Javascript, .NET und Go.

Timeout-Verhalten bei Bytecode-Commit und -Rollback

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

Auf der Client-Seite werden die Gremlin-Treiber tx.commit() und die tx.rollback() Aufrufe erst abgeschlossen, wenn der Server antwortet. 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 spezielle Gremlin-Sprachvariante.

Wenn Sie die Zeit, in der Ihre Anwendung auf ein commit() Oder wartet, einschränken müssenrollback(), können Sie die Parallelitätsfunktionen Ihrer Sprache verwenden, um ein clientseitiges Timeout festzulegen. Wenn das 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.

Serverseitige Transaktionsbereinigung

Wenn ein Client eine Transaktion unterbricht oder abbricht, ohne einen Commit oder Rollback vorzunehmen, verfügt Neptune über serverseitige Mechanismen, die die verwaiste Transaktion irgendwann bereinigen:

Diese Säuberungsmechanismen sind Sicherheitsnetze. Wir empfehlen Ihnen, Transaktionen immer dann explizit festzuschreiben oder rückgängig zu machen, wenn Sie mit ihnen fertig sind.