Una sesión inicia una Transacción
en el momento que se emite cualquier sentencia INSERT, UPDATE o DELETE (pero no
un TRUNCATE, que es un comando DDL, no un DDL). La transacción continúa a
través de cualquier numero de otros comandos DML hasta que la sesión emite un
COMMIT o un ROLLBACK. Sólo entonces los cambios se hacen permanentes y se hacen
visibles a otras sesiones (si es que se ha hecho un COMMIT, en lugar de un
ROLLBACK). No es posible anidar transacciones. El estándar SQL no permite que
un usuario inicie una transacción y luego comenzar otra antes de terminar la
primera. Esto se puede hacer con PL / SQL (lenguaje de tercera generación de
propiedad de Oracle), pero no con el estándar de la industria de SQL.
Las sentencias de
control de transacciones explícitas son COMMIT, ROLLBACK y SAVEPOINT. También
hay circunstancias distintas de un COMMIT o ROLLBACK que implícitamente
terminar una transacción:
n
Hacer
una declaración DDL o DCL.
n Cómo salir de la herramienta de
usuario (SQL * Plus o SQL Developer o cualquier otra cosa).
n Si la sesión de cliente muere.
n
Si
el sistema se bloquea.
Si un usuario emite un
comando DDL (CREATE , ALTER o DROP) o DCL ( GRANT o REVOKE ), la transacción
que está en curso (si los hay) se ha confirmado(commit) : será hecha permanente
y se hacen visibles al resto de usuarios. Esto es debido a que los comandos DDL
y DCL son en sí mismas transacciones. Si fuera posible ver el código fuente de
estos comandos, sería obvio. Se ajustan las estructuras de datos mediante la
realización de comandos DML contra las tablas que componen el diccionario de
datos, y estos comandos se terminan con un COMMIT. Si no fuera así, los cambios
realizados no se podía garantizar que sean permanentes. Dado que no es posible
en SQL para anidar transacciones, si el
usuario ya tiene una transacción que se ejecuta, la sentencias del usuario se confirmarían
con los comandos DDL y DCL. Si un usuario inicia una transacción mediante la
emisión de un comando DML y luego sale de la herramienta que está utilizando
sin emitir explícitamente o bien un COMMIT o un ROLLBACK, la transacción se
termina, pero si se termina con un COMMIT o un ROLLBACK depende totalmente de
cómo la herramienta está escrito . Muchas herramientas tendrán un
comportamiento diferente, dependiendo de cómo se sale de la herramienta.
Si la sesión de un
cliente falla por alguna razón, la base de datos siempre será deshacer la
transacción. Esta situación podría ser por varias razones: el proceso de
usuario puede morir o ser matado en el nivel del sistema operativo, la conexión
de red con el servidor de base de datos puede perderse, o la máquina donde la
herramienta de cliente se ejecuta puede fallar. En cualquiera de estos casos,
no hay ningún problema ordenada de una sentencia COMMIT o ROLLBACK, y
corresponde a la base de datos para detectar lo que ha sucedido. El
comportamiento es que la sesión es terminada, y una transacción activa se
revierte. El comportamiento es el mismo si el fallo está en el lado del
servidor. Si el servidor de base de datos se bloquea por cualquier razón, la
próxima vez que se pone en marcha todas las transacciones de las sesiones que
estaban en curso se reversan.
Comentarios
Publicar un comentario