Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Transacciones de Gremlin en Neptune

Hay varios contextos en los que se ejecutan las transacciones de Gremlin. Al trabajar con Gremlin, es importante entender el contexto en el que se trabaja y cuáles son sus implicaciones:

Para cualquiera de los contextos anteriores, existe el contexto adicional de la solicitud que se envía sin sesión o vinculada a una sesión.

Solicitudes sin sesión

Cuando no hay sesión, una solicitud equivale a una sola transacción.

En el caso de los scripts, esto implica que una o más instrucciones de Gremlin enviadas en una sola solicitud se confirmarán o anularán como una sola transacción. Por ejemplo:

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

En el caso del código de bytes, se realiza una solicitud sin sesión para cada recorrido que se genera y ejecuta desde 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();

Solicitudes vinculadas a una sesión

Cuando están vinculadas a una sesión, se pueden aplicar varias solicitudes en el contexto de una sola transacción.

En el caso de los scripts, esto implica que no es necesario concatenar todas las operaciones gráficas en un único valor de cadena integrado:

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 las sesiones basadas en scripts, al cerrar el cliente client.close() se confirma la transacción. No hay ningún comando de reversión explícito disponible en las sesiones basadas en scripts. Para forzar una reversión, puede hacer que la transacción falle emitiendo una consulta, por ejemplo, g.inject(0).fail('rollback') antes de cerrar el cliente.

En el caso del código de bytes, la transacción se puede controlar de forma explícita y la sesión se puede gestionar de forma transparente. Las variantes del lenguaje Gremlin (GLV) admiten la sintaxis tx() de Gremlin para utilizar commit() o rollback() en una transacción de la siguiente manera:

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

Aunque el ejemplo anterior está escrito en Java, también puedes usar esta tx() sintaxis en otros lenguajes. Para ver la sintaxis de transacciones específica de un idioma, consulte la sección Transacciones de la TinkerPop documentación de Apache para Java, Python, Javascript , .NET y Go.

Comportamiento de tiempo de espera para la confirmación y la reversión de código de bytes

Cuando se utilizan transacciones basadas en códigos de bytes con la tx() sintaxis, las rollback() operaciones commit() y no están sujetas a la configuración del tiempo de espera de las consultas. Ni el neptune_query_timeout parámetro global ni los valores de tiempo de espera por consulta establecidos se aplican a estas operaciones. evaluationTimeout En el servidor commit() y se rollback() ejecutan sin límite de tiempo hasta que se completen o se produzca un error.

En el lado del cliente, el controlador de Gremlin tx.commit() y las tx.rollback() llamadas no se completarán hasta que el servidor responda. Según el idioma, esto puede manifestarse como una llamada de bloqueo o una operación asíncrona no resuelta. Ningún controlador proporciona una configuración de tiempo de espera integrada que limite estas llamadas. Consulta la documentación de la API de tu variante específica del lenguaje Gremlin para obtener más información sobre el comportamiento de concurrencia en torno a estas funciones de transacción.

Si necesitas limitar el tiempo de espera de la aplicación para una commit() operaciónrollback(), puedes usar las funciones de simultaneidad de tu idioma para aplicar un tiempo de espera en el lado del cliente. Si se agota el tiempo de espera del lado del cliente, el servidor continúa procesando la operación. La operación del lado del servidor retiene un subproceso de trabajo hasta que se complete. Una vez transcurrido el tiempo de espera del lado del cliente, cierre la conexión y cree una nueva en lugar de volver a utilizar la conexión existente, ya que el estado de la transacción es indeterminado.

Server-side limpieza de transacciones

Si un cliente desconecta o abandona una transacción sin confirmarla ni revertirla, Neptune cuenta con mecanismos del lado del servidor que, en última instancia, eliminan la transacción huérfana:

Estos mecanismos de limpieza son redes de seguridad. Le recomendamos que siempre confirme o anule de forma explícita las transacciones cuando las haya terminado.