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](transactions.md) Gremlin. Quando si lavora con Gremlin è importante comprendere il contesto in cui si lavora e quali sono le relative implicazioni: + **`Script-based`**: le richieste vengono effettuate utilizzando stringhe Gremlin basate su testo, come queste: + Utilizzando il driver Java e `Client.submit(string)`. + Utilizzando la console Gremlin e `:remote connect`. + Utilizzando l'API HTTP. + **`Bytecode-based`**: le richieste vengono effettuate utilizzando il bytecode Gremlin serializzato tipico delle [varianti del linguaggio Gremlin](https://tinkerpop.apache.org/docs/current/reference/#gremlin-drivers-variants) (GLV). Ad esempio, utilizzando il driver Java, `g = traversal().withRemote(...)`. Per entrambi i contesti sopra descritti, esiste il contesto aggiuntivo della richiesta inviata come senza sessione o come associata a una sessione. **Nota** Le transazioni Gremlin devono sempre essere sottoposte a commit o rollback, in modo che le risorse lato server possano essere rilasciate. In caso di errore durante la transazione, è importante ripetere l'intera transazione e non solo la richiesta specifica non riuscita. ## 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')` **Nota** Una query del tipo`g.inject(0).fail('rollback')`, utilizzata per generare intenzionalmente un errore per forzare un rollback, produce un'eccezione sul client. Rileva e scarta l'eccezione risultante prima di chiudere il client. 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. [https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript-transactions](https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript-transactions) **avvertimento** Le query di sola lettura senza sessione vengono eseguite con isolamento [SNAPSHOT](transactions-isolation-levels.md), mentre le query di sola lettura eseguite all'interno di una transazione esplicita vengono eseguite con isolamento [SERIALIZABLE](transactions-isolation-levels.md). Le query di sola lettura eseguite con isolamento `SERIALIZABLE` comportano un sovraccarico maggiore e possono bloccarsi o essere bloccate da scritture simultanee, a differenza di quelle eseguite con isolamento `SNAPSHOT`. ## 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. **Importante** Se una `rollback()` chiamata `commit()` o richiede più tempo del previsto, potrebbe essere bloccata dal blocco di una transazione concorrente. Per ulteriori informazioni sui conflitti di blocco, vedere. [Risoluzione dei conflitti tramite timeout di attesa di blocco](transactions-neptune.md#transactions-neptune-conflicts) Se è necessario limitare il tempo di attesa dell'applicazione`rollback()`, è 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: + **Timeout della sessione: le** sessioni basate su bytecode che rimangono inattive per un periodo superiore alla durata massima della sessione (10 minuti) vengono chiuse e qualsiasi transazione aperta viene ripristinata. + **Timeout di inattività della connessione: Neptune chiude le** WebSocket connessioni inattive per circa 20 minuti. Quando la connessione si chiude, il server ripristina qualsiasi transazione aperta associata a quella connessione. Questi meccanismi di pulizia sono reti di sicurezza. Ti consigliamo di confermare o annullare sempre in modo esplicito le transazioni una volta terminate.