As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Transações do Gremlin no Neptune
<a name="access-graph-gremlin-transactions"></a>

Existem vários contextos nos quais as [transações](transactions.md) do Gremlin são executadas. Ao trabalhar com o Gremlin, é importante entender o contexto em que você está trabalhando e quais são suas implicações:
+ **`Script-based`**: as solicitações são feitas usando strings do Gremlin baseadas em texto, como esta:
  + Usar o driver Java e `Client.submit({{string}})`.
  + Usar o console do Gremlin e `:remote connect`.
  + Usar a API HTTP.
+ **`Bytecode-based`**: as solicitações são feitas usando o bytecode do Gremlin serializado típico das [Variantes da linguagem Gremlin](https://tinkerpop.apache.org/docs/current/reference/#gremlin-drivers-variants) (GLV).

  Por exemplo, usando o driver Java, `g = traversal().withRemote({{...}})`.

Para qualquer um dos contextos acima, há o contexto adicional da solicitação sendo enviada sem sessão ou vinculada a uma sessão.

**nota**  
 As transações do Gremlin sempre devem ser confirmadas ou revertidas, para que os recursos do lado do servidor possam ser liberados. No caso de erros durante a transação, é importante repetir toda a transação e não somente a solicitação específica que falhou. 

## Solicitações sem sessão
<a name="access-graph-gremlin-transactions-sessionless"></a>

 Quando não há sessão, uma solicitação equivale a uma única transação.

Para scripts, a implicação é que uma ou mais declarações do Gremlin enviadas em uma única solicitação serão confirmadas ou revertidas como uma única transação. Por exemplo:

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

Para bytecode, uma solicitação sem sessão é feita para cada percurso gerado e executado a partir de `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();
```

## Solicitações vinculadas a uma sessão
<a name="access-graph-gremlin-transactions-session-bound"></a>

Quando vinculadas a uma sessão, várias solicitações podem ser aplicadas no contexto de uma única transação.

Para scripts, a implicação é que não há necessidade de concatenar todas as operações do grafo em um único valor de string incorporado:

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

Para sessões baseadas em script, fechar o cliente com `client.close()` confirma a transação. Não há nenhum comando de reversão explícito disponível em sessões baseadas em script. Para forçar uma reversão, você pode fazer com que a transação falhe emitindo uma consulta, como `g.inject(0).fail('rollback')` antes de fechar o cliente.

**nota**  
Uma consulta como`g.inject(0).fail('rollback')`, usada para gerar um erro intencionalmente para forçar uma reversão, produz uma exceção no cliente. Capture e descarte a exceção resultante antes de fechar o cliente.

Para o bytecode, a transação pode ser controlada explicitamente e a sessão gerenciada de forma transparente. As Variantes da linguagem Gremlin (GLV) são compatíveis com a sintaxe `tx()` do Gremlin para `commit()` ou `rollback()` uma transação da seguinte forma:

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

Embora o exemplo acima esteja escrito em Java, você também pode usar essa `tx()` sintaxe em outras linguagens. [https://tinkerpop.apache.org/docs/current/reference/#gremlin-dotnet-transactions](https://tinkerpop.apache.org/docs/current/reference/#gremlin-dotnet-transactions)

**Atenção**  
As consultas somente leitura sem sessão são executadas em isolamento [SNAPSHOT](transactions-isolation-levels.md), mas as consultas somente leitura executadas em uma transação explícita são executadas em isolamento [SERIALIZABLE](transactions-isolation-levels.md). As consultas somente leitura executadas em isolamento `SERIALIZABLE` geram maior sobrecarga e podem bloquear ou bloqueadas por gravações simultâneas, ao contrário das executadas em isolamento `SNAPSHOT`.

## Comportamento de tempo limite para confirmação e reversão de bytecode
<a name="access-graph-gremlin-transactions-commit-rollback-timeout"></a>

Quando você usa transações baseadas em bytecode com a `tx()` sintaxe, as `rollback()` operações `commit()` e não estão sujeitas às configurações de tempo limite da consulta. Nem o `neptune_query_timeout` parâmetro global nem os valores de tempo limite por consulta definidos por meio `evaluationTimeout` se aplicam a essas operações. No servidor, `commit()` e `rollback()` executem sem limite de tempo até que eles concluam ou encontrem um erro.

No lado do cliente, o driver `tx.commit()` e as `tx.rollback()` chamadas do Gremlin não serão concluídos até que o servidor responda. Dependendo do idioma, isso pode se manifestar como uma chamada de bloqueio ou uma operação assíncrona não resolvida. Nenhum driver fornece uma configuração de tempo limite integrada que limite essas chamadas. Consulte a documentação da API para sua variante específica da linguagem Gremlin para obter detalhes sobre o comportamento de simultaneidade em torno desses recursos de transação.

**Importante**  
Se uma `rollback()` chamada `commit()` ou demorar mais do que o esperado, ela poderá ser bloqueada pela contenção de bloqueio de uma transação simultânea. Para obter mais informações sobre conflitos de bloqueio, consulte[Resolução de conflitos usando Lock-Wait tempos limite](transactions-neptune.md#transactions-neptune-conflicts).

Se você precisar limitar o tempo que seu aplicativo espera por um `commit()` ou`rollback()`, você pode usar os recursos de simultaneidade do seu idioma para aplicar um tempo limite do lado do cliente. Se o tempo limite do lado do cliente for acionado, o servidor continuará processando a operação. A operação do lado do servidor mantém um thread de trabalho até que seja concluída. Depois de um tempo limite do lado do cliente, feche a conexão e crie uma nova em vez de reutilizar a conexão existente, pois o estado da transação é indeterminado.

### Server-side limpeza de transações
<a name="access-graph-gremlin-transactions-server-side-cleanup"></a>

Se um cliente desconectar ou abandonar uma transação sem confirmar ou reverter, o Neptune tem mecanismos do lado do servidor que eventualmente eliminam a transação órfã:
+ **Tempo limite da sessão** — Bytecode-based as sessões que permanecem inativas por mais tempo do que a vida útil máxima da sessão (10 minutos) são fechadas e qualquer transação aberta é revertida.
+ **Tempo limite de inatividade da conexão — Neptune fecha as WebSocket conexões que estão** ociosas por aproximadamente 20 minutos. Quando a conexão é fechada, o servidor reverte qualquer transação aberta associada a essa conexão.

Esses mecanismos de limpeza são redes de segurança. Recomendamos que você sempre confirme ou reverta as transações de forma explícita ao finalizá-las.