Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Transazioni Gremlin in Neptune

Esistono diversi contesti in cui vengono eseguite le transazioni Gremlin. Quando si lavora con Gremlin è importante comprendere il contesto in cui si lavora e quali sono le relative implicazioni:

Per entrambi i contesti sopra descritti, esiste il contesto aggiuntivo della richiesta inviata come senza sessione o come associata a una sessione.

Richieste senza sessione

Quando è senza sessione, una richiesta equivale a una singola transazione.

Per gli script, l'implicazione è che una o più istruzioni Gremlin inviate in una singola richiesta verranno sottoposte a commit o rollback come singola transazione. Esempio:

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

Per il bytecode, viene effettuata una richiesta senza sessione per ogni attraversamento generato ed eseguito da 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();

Richieste associate a una sessione

Se associate a una sessione, è possibile applicare più richieste nel contesto di una singola transazione.

Per gli script, l'implicazione è che non è necessario concatenare tutte le operazioni del grafo in un unico valore di stringa incorporato:

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

Per le sessioni basate su script, la chiusura del client con conferma client.close() la transazione. Non è disponibile alcun comando di rollback esplicito nelle sessioni basate su script. Per forzare un rollback, puoi far fallire la transazione emettendo una query, ad esempio prima della chiusura del client. g.inject(0).fail('rollback')

Per quanto riguarda il bytecode, la transazione può essere controllata in modo esplicito e la sessione gestita in modo trasparente. Le varianti del linguaggio Gremlin (GLV) supportano la sintassi tx() di Gremlin per eseguire le operazioni di commit() o rollback() su una transazione come segue:

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

Sebbene l'esempio precedente sia scritto in Java, è possibile utilizzare questa tx() sintassi anche in altre lingue. Per la sintassi delle transazioni specifica del linguaggio, consulta la sezione Transazioni della documentazione di Apache TinkerPop per Java, Python, Javascript, .NET e Go.

Comportamento di timeout per bytecode, commit e rollback

Quando si utilizzano transazioni basate su bytecode con la tx() sintassi, le rollback() operazioni commit() and non sono soggette alle impostazioni di timeout delle query. A queste operazioni non si applicano né il neptune_query_timeout parametro globale né i valori di timeout per query impostati. evaluationTimeout Sul server, commit() ed rollback() eseguili senza limiti di tempo fino al completamento o al verificarsi di un errore.

Sul lato client, le tx.rollback() chiamate tx.commit() e il driver Gremlin non verranno completate finché il server non risponderà. A seconda della lingua, ciò potrebbe manifestarsi come una chiamata di blocco o un'operazione asincrona irrisolta. Nessun driver fornisce un'impostazione di timeout integrata che limiti queste chiamate. Consulta la documentazione dell'API per la tua variante linguistica Gremlin specifica per i dettagli sul comportamento di concorrenza relativo a queste funzionalità di transazione.

Se è necessario limitare il tempo di attesa dell'applicazionerollback(), è possibile utilizzare le funzionalità di concorrenza della lingua in uso per applicare un timeout lato client. commit() Se si attiva il timeout lato client, il server continua a elaborare l'operazione. L'operazione lato server mantiene un thread di lavoro fino al suo completamento. Dopo un timeout sul lato client, chiudi la connessione e creane una nuova anziché riutilizzare la connessione esistente, poiché lo stato della transazione è indeterminato.

Pulizia delle transazioni lato server

Se un client si disconnette o abbandona una transazione senza eseguire il commit o il rollback, Neptune dispone di meccanismi lato server che alla fine ripuliscono la transazione orfana:

Questi meccanismi di pulizia sono reti di sicurezza. Ti consigliamo di confermare o annullare sempre in modo esplicito le transazioni una volta terminate.