Comandos de administración de sesiones de JDBC (GoogleSQL)

El controlador JDBC de Spanner (conectividad a bases de datos de Java) admite sesiones de administración, que te permiten modificar el estado de tu conexión, ejecutar transacciones y ejecutar lotes de declaraciones de manera eficiente.

Los siguientes comandos se aplican a las bases de datos de dialectos de GoogleSQL.

Nota: Solo puedes usar instrucciones de administración de sesiones con el Controlador JDBC de Spanner. Las declaraciones de gestión de sesiones no funcionan en la las bibliotecas cliente, Google Cloud CLI o el controlador de JDBC que crea Simba.

Declaraciones de conexión

Las siguientes declaraciones realizan cambios o muestran propiedades de la conexión actual.

SOLO LECTURA

Un valor booleano que indica si la conexión es o no en modo de solo lectura. El valor predeterminado es false.

SHOW VARIABLE READONLY
SET READONLY = { true | false }

Puedes cambiar el valor de esta propiedad solo mientras no esté activa transacción.

▶ Ejemplo: Transacción de solo lectura (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo usar esta propiedad para ejecutar operaciones de solo lectura en Spanner.

SET READONLY = TRUE;
-- This transaction is a read-only transaction.
BEGIN TRANSACTION;

-- The following two queries both use the read-only transaction.
SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

SELECT Title
FROM Albums
ORDER BY Title;

-- This shows the read timestamp that was used for the two queries.
SHOW VARIABLE READ_TIMESTAMP;

-- This marks the end of the read-only transaction. The next statement starts
-- a new read-only transaction.
COMMIT;

AUTOCOMUNICACIÓN

Un valor booleano que indica si la conexión está o no en modo de confirmación automática. El valor predeterminado es true.

SHOW VARIABLE AUTOCOMMIT
SET AUTOCOMMIT = { true | false }

Puedes cambiar el valor de esta propiedad solo cuando no haya ninguna actividad transacción.

Cuando AUTOCOMMIT se establece como falso, se inicia automáticamente una nueva transacción después de ejecutar COMMIT o ROLLBACK. La primera sentencia que ejecutes inicia la transacción.

▶ Ejemplo: Confirmación automática (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo usar la propiedad autocommit.

-- The default value for AUTOCOMMIT is true.
SHOW VARIABLE AUTOCOMMIT;

-- This insert statement is automatically committed after it is executed, as
-- the connection is in autocommit mode.
INSERT INTO T (id, col_a, col_b) VALUES (1, 100, 1);

-- Turning off autocommit means that a new transaction is automatically started
-- when the next statement is executed.
SET AUTOCOMMIT = FALSE;
-- The following statement starts a new transaction.
INSERT INTO T (id, col_a, col_b) VALUES (2, 200, 2);

-- This statement uses the same transaction as the previous statement.
INSERT INTO T (id, col_a, col_b) VALUES (3, 300, 3);

-- Commit the current transaction with the two INSERT statements.
COMMIT;

-- Transactions can also be executed in autocommit mode by executing the BEGIN
-- statement.
SET AUTOCOMMIT = FALSE;

-- Execute a transaction while in autocommit mode.
BEGIN;
INSERT INTO T (id, col_a, col_b) VALUES (4, 400, 4);
INSERT INTO T (id, col_a, col_b) VALUES (5, 500, 5);
COMMIT;

RETRY_ABORTS_INTERNALLY

Un valor booleano que indica si la conexión se reintentó automáticamente transacciones de contenedores. El valor predeterminado es true.

SHOW VARIABLE RETRY_ABORTS_INTERNALLY
SET RETRY_ABORTS_INTERNALLY = { true | false }

Solo puedes cambiar el valor de esta propiedad después de que comience una transacción (consulta BEGIN TRANSACTION) y versiones anteriores todas las sentencias se ejecutan dentro de la transacción.

Cuando configuras RETRY_ABORTS_INTERNALLY como verdadero, la conexión mantiene una de todos los datos que la conexión muestra a la aplicación cliente. Esta para reintentar la transacción si Spanner la anula.

El valor predeterminado es true. Te recomendamos establecer este valor en false si tu la aplicación ya reintenta transacciones anuladas.

AUTOCOMMIT_DML_MODE

Una propiedad STRING que indica el modo de confirmación automática para Declaraciones de lenguaje de manipulación de datos (DML).

SHOW VARIABLE AUTOCOMMIT_DML_MODE
SET AUTOCOMMIT_DML_MODE = { 'TRANSACTIONAL' | 'PARTITIONED_NON_ATOMIC' }

Los siguientes son los valores posibles:

• En el modo TRANSACTIONAL, el controlador ejecuta las declaraciones DML como transacciones atómicas independientes. El controlador crea una nueva transacción, ejecuta la declaración DML y confirma la transacción cuando se ejecuta de manera correcta o revierte la transacción en caso de error.
• En el modo PARTITIONED_NON_ATOMIC, el controlador ejecuta declaraciones DML como declaraciones de actualización particionadas. Un grupo de anuncios particionado update puede ejecutarse como una serie de muchas transacciones, cada una de las cuales abarca un subconjunto de las filas afectadas. La instrucción particionada proporciona una semántica debilitada a cambio de una mejor escalabilidad y rendimiento.

El valor predeterminado es TRANSACTIONAL.

▶ Ejemplo: DML particionado (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ejecutar DML particionado con Controlador JDBC de Spanner.

-- Change autocommit DML mode to use Partitioned DML.
SET AUTOCOMMIT_DML_MODE = 'PARTITIONED_NON_ATOMIC';

-- Delete all singers that have been marked as inactive.
-- This statement is executed using Partitioned DML.
DELETE
FROM singers
WHERE active=false;

-- Change DML mode back to standard `TRANSACTIONAL`.
SET AUTOCOMMIT_DML_MODE = 'TRANSACTIONAL';

STATEMENT_TIMEOUT

Una propiedad de tipo STRING que indica el valor de tiempo de espera actual para las declaraciones.

SHOW VARIABLE STATEMENT_TIMEOUT
SET STATEMENT_TIMEOUT = { '<INT64>{ s | ms | us | ns }' | NULL }

El valor INT64 es un número entero seguido de un sufijo que indica la hora unidad. Un valor de NULL indica que no se estableció un valor de tiempo de espera. Si un tiempo de espera de la sentencia, las sentencias que tardan más que un valor de tiempo de espera especificado causará un error java.sql.SQLTimeoutException y invalidar la transacción.

Las unidades de tiempo admitidas son las que se muestran a continuación:

• s: Segundos
• ms: Milésimas de segundo
• us: Microsegundos
• ns: Nanosegundos

El valor predeterminado es NULL, lo que significa que no se estableció ningún valor de tiempo de espera.

El tiempo de espera de una declaración durante una transacción invalida la transacción, las sentencias posteriores en la transacción invalidada (excepto ROLLBACK) fallan, y el controlador de JDBC de Spanner arroja un java.sql.SQLTimeoutException.

READ_ONLY_STALENESS

Una propiedad de tipo STRING que indica la propiedad configuración de inactividad de solo lectura que Spanner usa para transacciones de solo lectura y consultas en AUTOCOMMIT .

SHOW VARIABLE READ_ONLY_STALENESS
SET READ_ONLY_STALENESS = staleness_type

staleness_type:

{ 'STRONG' 
  | 'MIN_READ_TIMESTAMP timestamp'
  | 'READ_TIMESTAMP timestamp'
  | 'MAX_STALENESS <INT64>{ s | ms | us | ns }'
  | 'EXACT_STALENESS <INT64>{ s | ms | us | ns }' }

El valor de inactividad de solo lectura se aplica a todos para las transacciones de solo lectura posteriores y para todas las consultas en modo AUTOCOMMIT.

El valor predeterminado es STRONG.

Las opciones de límite de marca de tiempo son las que se muestran a continuación:

• STRONG le indica a Spanner que realice una lectura sólida.
• MAX_STALENESS define el intervalo de tiempo que usa Spanner para realizar una lectura de inactividad limitada, en relación con now().
• MIN_READ_TIMESTAMP define el tiempo absoluto que Spanner usa para realizar lo siguiente: Una lectura de inactividad limitada.
• EXACT_STALENESS define el intervalo de tiempo que usa Spanner para realizar una lectura de inactividad exacta, en relación con now().
• READ_TIMESTAMP define el tiempo absoluto que Spanner usa para realizar una una lectura de inactividad exacta.

Las marcas de tiempo deben usar el siguiente formato:

YYYY-[M]M-[D]DT[[H]H:[M]M:[S]S[.DDDDDD]][timezone]

Las unidades de tiempo admitidas para configurar los valores MAX_STALENESS y EXACT_STALENESS son:

• s: Segundos
• ms: Milésimas de segundo
• us: Microsegundos
• ns: Nanosegundos

Puedes modificar el valor de esta propiedad solo mientras no esté activa transacción.

Nota: Puedes usar los valores MIN_READ_TIMESTAMP y MAX_STALENESS solo para consultas en modo AUTOCOMMIT.

▶ Ejemplo: Inactividad de solo lectura (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ejecutar consultas con una inactividad personalizada con el controlador JDBC de Spanner.

-- Set the read-only staleness to MAX_STALENESS 10 seconds.
SET READ_ONLY_STALENESS = 'MAX_STALENESS 10s';

-- Execute a query in auto-commit mode. This returns results that are up to
-- 10 seconds stale.
SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- Read-only staleness can also be applied to read-only transactions.
-- MAX_STALENESS is only allowed for queries in autocommit mode.
-- Change the staleness to EXACT_STALENESS and start a read-only transaction.
SET READ_ONLY_STALENESS = 'EXACT_STALENESS 10s';
BEGIN;
SET TRANSACTION READ ONLY;

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

SELECT Title, SingerId
FROM Albums
ORDER BY Title;

COMMIT;

-- Set the read staleness to an exact timestamp.
SET READ_ONLY_STALENESS = 'READ_TIMESTAMP 2024-01-26T10:36:00Z';

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

OPTIMIZER_VERSION

Una propiedad de tipo STRING que indica la versión del optimizador. La versión es un número entero o "LATEST".

SHOW VARIABLE OPTIMIZER_VERSION
SET OPTIMIZER_VERSION = { 'version'|'LATEST'|'' }

Establece la versión del optimizador que se utilizará para todas las siguientes sentencias en la conexión. Si la versión del optimizador se establece en '' (la cadena vacía), Spanner usa la versión más reciente. Si no se establece ninguna versión del optimizador, Spanner usa la versión del optimizador que se configura en la base de datos a nivel de organización.

El valor predeterminado es ''.

▶ Ejemplo: Versión del optimizador (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ejecutar consultas usando un bucket versión del optimizador con el Controlador JDBC de Spanner.

-- Set the optimizer version to 5 and execute a query.
SET OPTIMIZER_VERSION = '5';

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- Execute the same query with the latest optimizer version.
SET OPTIMIZER_VERSION = 'LATEST';

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- Revert back to using the default optimizer version that has been set for the
-- database.
SET OPTIMIZER_VERSION = '';

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

OPTIMIZER_STATISTICS_PACKAGE

Una propiedad de tipo STRING que indica la propiedad paquete de estadísticas del optimizador que usa esta conexión.

SHOW VARIABLE OPTIMIZER_STATISTICS_PACKAGE
SET OPTIMIZER_STATISTICS_PACKAGE = { 'package'|'' }

Establece el paquete de estadísticas del optimizador que se usará para todas las sentencias siguientes en la conexión. <package> debe ser un nombre de paquete válido. Si no hay optimizador de estadísticas, Spanner usa las estadísticas del optimizador que se configura a nivel de la base de datos.

El valor predeterminado es ''.

▶ Ejemplo: Paquete de estadísticas del optimizador (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ejecutar consultas usando un bucket paquete de estadísticas del optimizador con el controlador JDBC de Spanner.

-- Show the available optimizer statistics packages in this database.
SELECT * FROM INFORMATION_SCHEMA.SPANNER_STATISTICS;

-- Set the optimizer statistics package and execute a query.
SET OPTIMIZER_STATISTICS_PACKAGE = 'auto_20240124_06_47_29UTC';

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- Execute the same query with the default optimizer statistics package.
SET OPTIMIZER_STATISTICS_PACKAGE = '';

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

RETURN_COMMIT_STATS

Una propiedad de tipo BOOL que indica si se deben mostrar estadísticas para transacciones en esta conexión. Para ver las estadísticas mostradas, ejecuta el comando SHOW VARIABLE COMMIT_RESPONSE

SHOW VARIABLE RETURN_COMMIT_STATS
SET RETURN_COMMIT_STATS = { true | false }

El valor predeterminado es false.

▶ Ejemplo: Estadísticas de confirmación (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ver las estadísticas de confirmación de una transacción con el controlador JDBC de Spanner.

-- Enable the returning of commit stats.
SET RETURN_COMMIT_STATS = true;

-- Execute a transaction.
BEGIN;
INSERT INTO T (id, col_a, col_b)
VALUES (1, 100, 1), (2, 200, 2), (3, 300, 3);
COMMIT;

-- View the commit response with the transaction statistics for the last
-- transaction that was committed.
SHOW VARIABLE COMMIT_RESPONSE;

RPC_PRIORITY

Una propiedad de tipo STRING que indica la prioridad relativa para Solicitudes de Spanner. La prioridad sirve de indicio Es el programador de Spanner y no garantiza el orden de ejecución.

SHOW VARIABLE RPC_PRIORITY
SET RPC_PRIORITY = {'HIGH'|'MEDIUM'|'LOW'|'NULL'}

'NULL' significa que no se debe incluir ninguna sugerencia en la solicitud.

El valor predeterminado es 'NULL'.

También puedes usar una sugerencia de instrucción para especificar la prioridad de RPC:

@{RPC_PRIORITY=PRIORITY_LOW} SELECT * FROM Albums

Para obtener más información, consulta Priority.

Etiquetas

Las siguientes declaraciones administran las etiquetas de solicitud y transacción.

STATEMENT_TAG

Una propiedad de tipo STRING que contiene la etiqueta de solicitud para la siguiente declaración.

SHOW VARIABLE STATEMENT_TAG
SET STATEMENT_TAG = 'tag-name'

Establece la etiqueta de solicitud de la próxima declaración que se ejecutará. Solo uno la etiqueta de recurso se puede establecer por instrucción. La etiqueta no abarca varias sentencias. it se debe establecer por estado de cuenta. Para quitar una etiqueta de solicitud, configúrala a la cadena vacía ('').

El valor predeterminado es ''.

Puedes establecer etiquetas de transacción y de instrucción para la misma declaración.

También puedes usar una sugerencia de instrucción para agregar una etiqueta de instrucción:

@{STATEMENT_TAG='my-tag'} SELECT * FROM Albums

Para obtener más información, consulta Soluciona problemas relacionados con las etiquetas de solicitud y de transacción.

▶ Ejemplo: Etiquetas de la sentencia (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo establecer etiquetas de sentencia con el Controlador JDBC de Spanner.

-- Set the statement tag that should be included with the next statement.
SET STATEMENT_TAG = 'tag1';
SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- The statement tag property is cleared after each statement execution.
SHOW VARIABLE STATEMENT_TAG;
-- Set another tag for the next statement.
SET STATEMENT_TAG = 'tag2';
SELECT Title
FROM Albums
ORDER BY Title;

-- Set a statement tag with a query hint.
@{STATEMENT_TAG = 'tag3'}
SELECT TrackNumber, Title
FROM Tracks
WHERE AlbumId=1 AND SingerId=1
ORDER BY TrackNumber;

TRANSACTION_TAG

Una propiedad de tipo STRING que contiene la etiqueta de transacción para la siguiente transacción.

SHOW VARIABLE TRANSACTION_TAG
SET TRANSACTION_TAG = 'tag-name'

Establece la etiqueta de transacción de la transacción actual que se ejecutará. Solo uno la etiqueta de recurso por transacción. La etiqueta no abarca varias transacciones. it debe establecerse por transacción. Para quitar una etiqueta de transacción, configúrala en una cadena vacía (''). La etiqueta de transacción debe establecerse antes del se ejecutaron todas las sentencias en la transacción.

El valor predeterminado es ''.

Puedes establecer etiquetas de transacción y de instrucción para la misma declaración.

Para obtener más información, consulta Soluciona problemas relacionados con las etiquetas de solicitud y de transacción.

▶ Ejemplo: Etiquetas de transacción (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo configurar etiquetas de transacción con el Controlador JDBC de Spanner.

BEGIN;
-- Set the transaction tag for the current transaction.
SET TRANSACTION_TAG = 'transaction-tag-1';

-- Set the statement tag that should be included with the next statement.
-- The statement will include both the statement tag and the transaction tag.
SET STATEMENT_TAG = 'select-statement';
SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- The statement tag property is cleared after each statement execution.
SHOW VARIABLE STATEMENT_TAG;

-- Set another tag for the next statement.
SET STATEMENT_TAG = 'insert-statement';
INSERT INTO T (id, col_a, col_b)
VALUES (1, 100, 1);

COMMIT;

-- The transaction tag property is cleared when the transaction finishes.
SHOW VARIABLE TRANSACTION_TAG;

Declaraciones de transacciones

Las siguientes declaraciones administran y confirman transacciones de Spanner.

READ_TIMESTAMP

SHOW VARIABLE READ_TIMESTAMP

Muestra un conjunto de resultados con una fila y una columna de tipo TIMESTAMP que contienen la marca de tiempo de lectura de la transacción de solo lectura más reciente. Esta declaración muestra una marca de tiempo solo cuando una transacción de solo lectura aún está activa y ejecuta al menos una consulta, o inmediatamente después de que se confirma una transacción de solo lectura y antes de que comience una nueva transacción. De lo contrario, el resultado es NULL.

▶ Ejemplo: Marca de tiempo de lectura (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ver la marca de tiempo de la última lectura de un una operación de solo lectura con el controlador JDBC de Spanner.

-- Execute a query in autocommit mode using the default read-only staleness
-- (strong).
SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- Show the read timestamp that was used for the previous query.
SHOW VARIABLE READ_TIMESTAMP;

-- Set a non-deterministic read-only staleness and execute the same query.
SET READ_ONLY_STALENESS = 'MAX_STALENESS 20s';

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- Show the read timestamp that was used for the previous query. The timestamp
-- is determined by Spanner, and is guaranteed to be no less than
-- 20 seconds stale.
SHOW VARIABLE READ_TIMESTAMP;

-- The read timestamp of a read-only transaction can also be retrieved.
SET READ_ONLY_STALENESS = 'STRONG';
BEGIN;
SET TRANSACTION READ ONLY;

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- Show the read timestamp of the current read-only transaction. All queries in
-- this transaction will use this read timestamp.
SHOW VARIABLE READ_TIMESTAMP;

SELECT Title
FROM Albums
ORDER BY Title;

-- The read timestamp is the same as for the previous query, as all queries in
-- the same transaction use the same read timestamp.
SHOW VARIABLE READ_TIMESTAMP;

COMMIT;

COMMIT_TIMESTAMP

SHOW VARIABLE COMMIT_TIMESTAMP

Muestra un conjunto de resultados con una fila y una columna de tipo TIMESTAMP que contienen la marca de tiempo de confirmación de la última transacción de lectura y escritura que Spanner se confirmó. Esta sentencia devuelve una marca de tiempo solo cuando Lo ejecutas después de confirmar una transacción de lectura y escritura, y antes de ejecutar cualquier declaración de cambio de esquema, SELECT o DML posterior. De lo contrario, el el resultado es NULL.

▶ Ejemplo: Marca de tiempo de confirmación (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ver la última marca de tiempo de confirmación de un de escritura de instancias con el controlador de JDBC de Spanner.

-- Execute a DML statement.
INSERT INTO T (id, col_a, col_b)
VALUES (1, 100, 1), (2, 200, 2), (3, 300, 3);

-- Show the timestamp that the statement was committed.
SHOW VARIABLE COMMIT_TIMESTAMP;

COMMIT_RESPONSE

SHOW VARIABLE COMMIT_RESPONSE

Muestra un conjunto de resultados con una fila y dos columnas:

• COMMIT_TIMESTAMP (tipo=TIMESTAMP) indica cuándo se se confirmó la transacción.
• MUTATION_COUNT (tipo=INT64) indica cuántas mutaciones se aplicaron en la transacción confirmada. Este valor siempre está vacío cuando se ejecuta en la emulador.

El recuento de mutaciones solo está disponible si SET RETURN_COMMIT_STATS Se establece en true antes de la confirmación de la transacción.

▶ Ejemplo: Confirmación de la respuesta (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ver la última respuesta de confirmación para un de escritura de instancias con el controlador de JDBC de Spanner.

-- Enable returning commit stats in addition to the commit timestamp.
SET RETURN_COMMIT_STATS = true;

-- Execute a DML statement.
INSERT INTO T (id, col_a, col_b)
VALUES (1, 100, 1), (2, 200, 2), (3, 300, 3);

-- Show the timestamp that the statement was committed.
SHOW VARIABLE COMMIT_RESPONSE;

BEGIN [TRANSACTION]

BEGIN [TRANSACTION]

Inicia una transacción nueva. La palabra clave TRANSACTION es opcional.

• Usa COMMIT o ROLLBACK para finalizar una transacción.
• Si habilitaste el modo AUTOCOMMIT, esta declaración quitará la conexión del modo AUTOCOMMIT de forma temporal. La conexión regresa al modo AUTOCOMMIT cuando finaliza la transacción.
• El modo de transacción está determinado por la configuración actual de READONLY para esta conexión. Este valor se establece con SET READONLY = {TRUE | FALSE}. kubectl.
• Se puede cambiar el modo de transacción ejecutando SET TRANSACTION READ ONLY o SET TRANSACTION READ WRITE directamente después de ejecutar BEGIN [TRANSACTION].

Puedes ejecutar esta declaración solo si no hay transacciones activas.

▶ Ejemplo: COMENZAR TRANSACCIÓN (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo iniciar distintos tipos de transacciones con el controlador JDBC de Spanner.

-- This starts a transaction using the current defaults of this connection.
-- The value of READONLY determines whether the transaction is a
-- read-write or a read-only transaction.

BEGIN;
INSERT INTO T (id, col_a, col_b)
VALUES (1, 100, 1);
COMMIT;

-- Set READONLY to TRUE to use read-only transactions by default.
SET READONLY=TRUE;

-- This starts a read-only transaction.
BEGIN;
SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;
COMMIT;

-- Execute 'SET TRANSACTION READ WRITE' or 'SET TRANSACTION READ ONLY' directly
-- after the BEGIN statement to override the current default of the connection.
SET READONLY=FALSE;
BEGIN;
SET TRANSACTION READ ONLY;
SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;
COMMIT;

COMMIT [TRANSACTION]

COMMIT [TRANSACTION]

Confirma la transacción actual. La palabra clave TRANSACTION es opcional.

• Cuando se confirma una transacción de lectura y escritura, se realizan todas las actualizaciones de esta transacción visible para otras transacciones y libera todos los bloqueos de la transacción Spanner
• La confirmación de una transacción de solo lectura finaliza la transacción de solo lectura actual. Cualquier declaración posterior inicia una nueva transacción. No hay diferencia semántica entre COMMIT y ROLLBACK para una transacción de solo lectura.

Puedes ejecutar esta declaración solo mientras haya una transacción activa.

▶ Ejemplo: TRANSACCIÓN EN COMPROMISO (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo confirmar una transacción con el Controlador JDBC de Spanner.

-- Execute a regular read-write transaction.
BEGIN;
INSERT INTO T (id, col_a, col_b)
VALUES (1, 100, 1);
COMMIT;

-- Execute a read-only transaction. Read-only transactions also need to be
-- either committed or rolled back in the Spanner JDBC driver in order
-- to mark the end of the transaction.
BEGIN;
SET TRANSACTION READ ONLY;
SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;
COMMIT;

ROLLBACK [TRANSACTION]

ROLLBACK [TRANSACTION]

Realiza una ROLLBACK de la transacción actual. Las palabras clave TRANSACTION son opcional.

• Realizar una ROLLBACK de una transacción de lectura y escritura borra cualquier búfer almacenado mutaciones, revierte la transacción en Spanner y cualquier bloqueo que mantuviera la transacción.
• Si realizas una ROLLBACK de una transacción de solo lectura, finalizas la transacción de solo lectura actual. Las declaraciones posteriores inician una nueva transacción. No hay diferencia semántica entre COMMIT y ROLLBACK para una transacción de solo lectura en una conexión.

Puedes ejecutar esta declaración solo mientras haya una transacción activa.

▶ Ejemplo: TRANSACCIÓN DE REVERSIÓN (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo revertir una transacción con el Controlador JDBC de Spanner.

-- Use ROLLBACK to undo the effects of a transaction.
BEGIN;
INSERT INTO T (id, col_a, col_b)
VALUES (1, 100, 1);
-- This ensures that the insert statement is not persisted in the database.
ROLLBACK;

-- Read-only transactions also need to be either committed or rolled back in the
-- Spanner JDBC driver in order to mark the end of the transaction.
-- There is no semantic difference between rolling back or committing a
-- read-only transaction.
BEGIN;
SET TRANSACTION READ ONLY;
SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;
ROLLBACK;

SET TRANSACTION

SET TRANSACTION { READ ONLY | READ WRITE }

Establece el modo de transacción para la transacción actual.

Puedes ejecutar esta instrucción solo cuando AUTOCOMMIT sea false o si tienes comenzaron una transacción mediante la ejecución de BEGIN [TRANSACTION] y aún no ejecutaste ninguna instrucción en la transacción.

Esta sentencia establece el modo de transacción solo para la transacción actual. Cuándo la transacción se confirma o revierte, la siguiente transacción usa la configuración modo para la conexión (consulta SET READONLY).

Nota: No puedes establecer el modo de transacción en READ WRITE si la conexión está en modo READ ONLY.

▶ Ejemplo: ESTABLECER TRANSACCIÓN (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo establecer características de transacción con el Controlador JDBC de Spanner.

-- Start a transaction and set the transaction mode to read-only.
BEGIN;
SET TRANSACTION READ ONLY;

SELECT FirstName, LastName
FROM Singers
ORDER BY LastName;

-- Commit the read-only transaction to mark the end of the transaction.
COMMIT;

-- Start a transaction and set the transaction mode to read-write.
BEGIN;
SET TRANSACTION READ WRITE;

INSERT INTO T (id, col_a, col_b)
VALUES (1, 100, 1);

COMMIT;

Declaraciones por lotes

Las siguientes instrucciones administran lotes de declaraciones DDL y envían esos lotes a Spanner.

START BATCH DDL

START BATCH DDL

Inicia un lote de declaraciones de DDL en la conexión. Todas las declaraciones posteriores durante el lote deben ser declaraciones de DDL. Las declaraciones DDL se almacenan en búfer de manera local. y se envían a Spanner como un lote cuando ejecutas RUN BATCH. Ejecutar varias declaraciones de DDL como un lote suele ser más rápido que ejecutar las declaraciones por separado.

Puedes ejecutar esta declaración solo si no hay transacciones activas.

▶ Ejemplo: Lote de DDL (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ejecutar un lote de DDL con las Controlador JDBC de Spanner.

-- Start a DDL batch. All following statements must be DDL statements.
START BATCH DDL;

-- This statement is buffered locally until RUN BATCH is executed.
CREATE TABLE Singers (
  SingerId  INT64 NOT NULL,
  FirstName STRING(MAX),
  LastName  STRING(MAX)
) PRIMARY KEY (SingerId);

-- This statement is buffered locally until RUN BATCH is executed.
CREATE TABLE Albums (
  AlbumId  INT64 NOT NULL,
  Title    STRING(MAX),
  SingerId INT64,
  CONSTRAINT fk_albums_singers FOREIGN KEY (SingerId) REFERENCES Singers (SingerId)
) PRIMARY KEY (AlbumId);

-- This runs the DDL statements as one batch.
RUN BATCH;

RUN BATCH

RUN BATCH

Envía todas las declaraciones de DDL almacenadas en búfer en el lote de DDL actual a la base de datos. espera a que Spanner ejecute estas instrucciones y finaliza el lote de DDL actual.

Si Spanner no puede ejecutar al menos una declaración DDL, RUN BATCH devuelve un error para la primera declaración DDL que Spanner no puede ejecutar. De lo contrario, RUN BATCH se muestra de forma correcta.

Nota: Si una declaración DDL en el lote muestra un error, Spanner podría haber aplicado las declaraciones DDL anteriores en el mismo lote al en tu base de datos.

ABORT LOTES [TRANSACTION]

Borra todas las declaraciones de DDL almacenadas en búfer en el lote de DDL actual y finaliza el lote.

Puedes ejecutar esta declaración solo cuando un lote de DDL está activo. Puedes usar ABORT BATCH sin importar si el lote tiene o no declaraciones de DDL almacenadas en búfer. Se anularán todas las declaraciones DDL anteriores del lote.

▶ Ejemplo: Anular lote de DDL (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo anular un lote de DDL con la Controlador JDBC de Spanner.

-- Start a DDL batch. All following statements must be DDL statements.
START BATCH DDL;

-- The following statements are buffered locally.
CREATE TABLE Singers (
  SingerId  INT64 NOT NULL,
  FirstName STRING(MAX),
  LastName  STRING(MAX)
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
  AlbumId  INT64 NOT NULL,
  Title    STRING(MAX),
  SingerId INT64,
  CONSTRAINT fk_albums_singers FOREIGN KEY (SingerId) REFERENCES Singers (SingerId)
) PRIMARY KEY (AlbumId);

-- This aborts the DDL batch and removes the DDL statements from the buffer.
ABORT BATCH;

INICIAR DML POR BATCH y EJECUTAR Lote

Las siguientes declaraciones agrupan las dos declaraciones DML y las envían una llamada al servidor. Un lote de DML se puede ejecutar como parte de una transacción o en el modo de confirmación automática.

START BATCH DML;
INSERT INTO MYTABLE (ID, NAME) VALUES (1, 'ONE');
INSERT INTO MYTABLE (ID, NAME) VALUES (2, 'TWO');
RUN BATCH;

▶ Ejemplo: Lote DML (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo ejecutar un lote de DML con las Controlador JDBC de Spanner.

-- Start a DML batch. All following statements must be a DML statement.
START BATCH DML;

-- The following statements are buffered locally.
INSERT INTO MYTABLE (ID, NAME) VALUES (1, 'ONE');
INSERT INTO MYTABLE (ID, NAME) VALUES (2, 'TWO');

-- This sends the statements to Spanner.
RUN BATCH;

-- DML batches can also be part of a read/write transaction.
BEGIN;
-- Insert a row using a single statement.
INSERT INTO MYTABLE (ID, NAME) VALUES (3, 'THREE');

-- Insert two rows using a batch.
START BATCH DML;
INSERT INTO MYTABLE (ID, NAME) VALUES (4, 'FOUR');
INSERT INTO MYTABLE (ID, NAME) VALUES (5, 'FIVE');
RUN BATCH;

-- Rollback the current transaction. This rolls back both the single DML
-- statement and the DML batch.
ROLLBACK;

Declaraciones de consulta particionadas y Data Boost

La partitionQuery La API divide una consulta en partes más pequeñas, o particiones, y usa varias para recuperar las particiones en paralelo. Cada partición se identifica con un token de partición. La API de PartitionQuery tiene una latencia más alta que la estándar Query API, ya que solo está diseñada para operaciones masivas como exportar o analizar toda la base de datos.

Data Boost le permite ejecutar consultas de análisis y exportaciones de datos con un en las cargas de trabajo existentes en la instancia aprovisionada de Spanner. Data Boost solo admite consultas particionadas.

Puedes habilitar Data Boost con la sentencia SET DATA_BOOST_ENABLED.

El controlador JDBC de Spanner admite tres alternativas para ejecutar para consultas particionadas:

• SET AUTO_PARTITION_MODE = true
• RUN PARTITIONED QUERY sql
• PARTITION sql seguido de varios RUN PARTITION 'partition-token'

Cada uno de estos métodos se describe en las siguientes secciones.

DATA_BOOST_ENABLED

Una propiedad de tipo BOOL que indica si esta conexión debe usar Data Boost para consultas particionadas. Predeterminado es false.

SHOW VARIABLE DATA_BOOST_ENABLED
SET DATA_BOOST_ENABLED = { true | false }

▶ Ejemplo: Ejecuta una consulta con Data Boost (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo realizar una consulta usando Data Boost con la Controlador JDBC de Spanner.

-- Enable Data Boost on this connection.
SET DATA_BOOST_ENABLED = true;

-- Execute a partitioned query. Data Boost is only used for partitioned queries.
RUN PARTITIONED QUERY SELECT FirstName, LastName FROM Singers;

Para ver un ejemplo completo, consulta DataBoostExample.

AUTO_PARTITION_MODE

Una propiedad de tipo BOOL que indica si la conexión usa automáticamente las consultas particionadas para todas las consultas que se ejecutan.

SHOW VARIABLE AUTO_PARTITION_MODE
SET AUTO_PARTITION_MODE = { true | false}

• Establece esta variable en true si deseas que la conexión use para todas las consultas que se ejecutan.
• También establece DATA_BOOST_ENABLED en true si deseas que para usar Data Boost para todos para tus consultas.

El valor predeterminado es false.

▶ Ejemplo: Ejecutar (haz clic para expandir)

En este ejemplo, se ejecutan dos consultas con el controlador JDBC de Spanner mediante Data Boost

SET AUTO_PARTITION_MODE = true
SET DATA_BOOST_ENABLED = true
SELECT FirstName, LastName FROM Singers
SELECT SingerId, Title FROM Albums

Para ver un ejemplo completo, consulta AutoPartitionModeExample.

EJECUTAR CONSULTA PARTICIPADA

RUN PARTITIONED QUERY <sql>

Ejecuta una consulta como una consulta particionada en Spanner. Asegúrate de que DATA_BOOST_ENABLED se configura como true para ejecutar la consulta. Data Boost:

SET DATA_BOOST_ENABLED = true
RUN PARTITIONED QUERY SELECT FirstName, LastName FROM Singers

El controlador JDBC de Spanner particiona la consulta y la ejecuta particiones en paralelo. Los resultados se combinan en un conjunto de resultados y se muestran a la aplicación. Se puede establecer la cantidad de subprocesos de trabajo que ejecutan particiones con la variable MAX_PARTITIONED_PARALLELISM

Para ver un ejemplo completo, consulta RunPartitionedQueryExample.

PARTITION <SQL>

PARTITION <sql>

Crea una lista de particiones para ejecutar una consulta en Spanner. y muestra una lista de tokens de partición. Cada token de partición se puede ejecutado en una conexión independiente en el mismo cliente o en otro mediante el Comando RUN PARTITION 'partition-token'.

▶ Ejemplo: Consulta de partición (haz clic para expandir)

En el siguiente ejemplo, se muestra cómo particionar una consulta y, luego, ejecutar cada una por separado con el controlador JDBC de Spanner.

-- Partition a query. This returns a list of partition tokens that can be
-- executed either on this connection or on any other connection to the same
-- database.
PARTITION SELECT FirstName, LastName FROM Singers;

-- Run the partitions that were returned from the previous statement.
RUN PARTITION 'partition-token-1';
RUN PARTITION 'partition-token-2';

Para ver un ejemplo completo, consulta PartitionQueryExample.

RUN PARTITION “partition-token”

RUN PARTITION 'partition-token'

Ejecuta una partición de consulta que PARTITION mostró anteriormente. kubectl. El comando se puede ejecutar con cualquier conexión que esté conectada a la misma base de datos que la que creó los tokens de partición.

MAX_PARTITIONED_PARALLELISM

Una propiedad de tipo INT64 que indica la cantidad de subprocesos de trabajo que El controlador JDBC de Spanner usa para ejecutar particiones. Este valor se usa para lo siguiente:

• AUTO_PARTITION_MODE = true
• RUN PARTITIONED QUERY sql

SHOW VARIABLE MAX_PARTITIONED_PARALLELISM
SET MAX_PARTITIONED_PARALLELISM = <INT64>

Establece la cantidad máxima de subprocesos de trabajo que el controlador de JDBC de Spanner que puedes usar para ejecutar particiones. Establecer este valor en 0 indica a Controlador JDBC de Spanner para usar la cantidad de núcleos de CPU en el cliente máquina como el máximo.

El valor predeterminado es 0.

Comandos Savepoint

Con las siguientes instrucciones, se habilitan e inhabilitan los modelos puntos de guardado en las transacciones. Puedes crear un punto de guardado llamando al java.sql.Connection#setSavepoint() .

El controlador JDBC de Spanner emula los puntos de guardado para admitir frameworks en las transacciones anidadas. Los puntos de guardado se emulan manteniendo un registro de una suma de comprobación en ejecución para los resultados que han devuelto las sentencias de la transacción. Cuando se revierte a un punto de guardado, el El controlador JDBC de Spanner revierte la transacción y, luego, vuelve a intentar la hasta el punto en el que se estableció el punto de guardado. La suma de comprobación del reintentos se compara con la suma de comprobación de la transacción inicial para verificar que el se mostraron los mismos resultados.

SAVEPOINT_SUPPORT

SHOW VARIABLE SAVEPOINT_SUPPORT
SET SAVEPOINT_SUPPORT = { 'DISABLED' | 'FAIL_AFTER_ROLLBACK' | 'ENABLED' }

Una propiedad de tipo STRING que indica el SAVEPOINT_SUPPORT actual configuración. Los valores posibles son:

• DISABLED: Todos los comandos de punto de guardado están inhabilitados y fallarán.
• FAIL_AFTER_ROLLBACK: Los comandos de Savepoint están habilitados. Revierte a un Savepoint revierte la transacción completa. La transacción falla si intentas usar la transacción después de revertir a un punto de guardado.
• ENABLED: Todos los comandos de punto de guardado están habilitados. Revierte a un punto de guardado revertirá la transacción y se volverá a intentar en el punto de guardado. Esta la operación falla con un error AbortedDueToConcurrentModificationException si los datos subyacentes utilizados por la transacción hasta el punto de guardado cambió.

El valor predeterminado es FAIL_AFTER_ROLLBACK.

Puedes cambiar el valor de esta variable solo cuando no esté activa transacción.

▶ Ejemplo: Compatibilidad con Savepoint (haz clic para expandir)

El siguiente ejemplo muestra cómo habilitar e inhabilitar la compatibilidad con puntos de guardado en el controlador JDBC de Spanner.

try (Connection connection =
    DriverManager.getConnection(
        String.format(
            "jdbc:cloudspanner:/projects/%s/instances/%s/databases/%s",
            "my-project", "my-instance", "my-database"))) {
  // Savepoints can only be used when AutoCommit=false.
  connection.setAutoCommit(false);

  // Disables setting a savepoint.
  connection.createStatement().execute("SET SAVEPOINT_SUPPORT='DISABLED'");
  // The following statement fails because savepoints have been disabled.
  connection.setSavepoint("my_savepoint1");

  // Enables setting a savepoint and releasing a savepoint.
  // Rolling back to a savepoint is disabled.
  connection.createStatement().execute("SET SAVEPOINT_SUPPORT='FAIL_AFTER_ROLLBACK'");
  Savepoint mySavepoint2 = connection.setSavepoint("my_savepoint2");
  connection.createStatement().execute("insert into my_table (id, value) values (1, 'One')");
  connection.releaseSavepoint(mySavepoint2);
  connection.commit();

  // Enables setting, releasing and rolling back to a savepoint.
  connection.createStatement().execute("SET SAVEPOINT_SUPPORT='ENABLED'");
  Savepoint mySavepoint3 = connection.setSavepoint("my_savepoint3");
  connection.createStatement().execute("insert into my_table (id, value) values (2, 'Two')");
  connection.rollback(mySavepoint3);
}

¿Qué sigue?

Obtén más información para conectar JDBC a una base de datos de dialectos de GoogleSQL.