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

En el caso de 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, puedes provocar un error en la transacción 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 puede utilizar esta tx() sintaxis en otros lenguajes. Para ver la sintaxis de transacciones específica del idioma, consulte la sección Transacciones de la TinkerPop documentación de Apache para Java, Python, Javascript, .NET y Go.

Comportamiento del tiempo de espera para confirmar y revertir el 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 de 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 rollback() ejecútelos sin límite de tiempo hasta que se completen o se produzca un error.

En el lado del cliente, las tx.rollback() llamadas tx.commit() y las llamadas del controlador Gremlin 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 sin resolver. Ningún controlador proporciona una configuración de tiempo de espera integrada que limite estas llamadas. Consulta la documentación de la API correspondiente a tu variante específica del lenguaje Gremlin para obtener más información sobre el comportamiento de simultaneidad en relación con estas funciones de transacción.

Si necesita limitar el tiempo que la aplicación espera a una commit() orollback(), puede utilizar las funciones de simultaneidad de su idioma para aplicar un tiempo de espera por parte 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 completa. 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.

Limpieza de transacciones del lado del servidor

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

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