# Comparación de los niveles de aislamiento de Babelfish y SQL Server
<a name="babelfish-transaction.examples"></a>

 A continuación se muestran algunos ejemplos sobre los matices de la forma en que SQL Server y Babelfish implementan los niveles de aislamiento ANSI. 

**nota**  
El nivel de aislamiento `REPEATABLE READ` y `SNAPSHOT` son iguales en Babelfish.
El nivel de aislamiento `READ UNCOMMITTED` y `READ COMMITTED` son iguales en Babelfish.

En el ejemplo siguiente, se muestra cómo crear la tabla base para todos los ejemplos que se mencionan a continuación:

```
CREATE TABLE employee (
    id sys.INT NOT NULL PRIMARY KEY,
    name sys.VARCHAR(255)NOT NULL,
    age sys.INT NOT NULL
);
INSERT INTO employee (id, name, age) VALUES (1, 'A', 10);
INSERT INTO employee (id, name, age) VALUES (2, 'B', 20);
INSERT INTO employee (id, name, age) VALUES (3, 'C', 30);
```

**Topics**
+ [`READ UNCOMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ UNCOMMITTED`](#babelfish-transaction.examples.unc)
+ [`READ COMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ COMMITTED`](#babelfish-transaction.examples.com)
+ [`READ COMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ COMMITTED SNAPSHOT`](#babelfish-transaction.examples.snapshot)
+ [`REPEATABLE READ` de Babelfish en comparación con el nivel de aislamiento de SQL Server `REPEATABLE READ`](#babelfish-transaction.examples.read)
+ [`SERIALIZABLE` de Babelfish en comparación con el nivel de aislamiento de SQL Server `SERIALIZABLE`](#babelfish-transaction.examples.serialize)

## `READ UNCOMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ UNCOMMITTED`
<a name="babelfish-transaction.examples.unc"></a>

La siguiente tabla proporciona detalles sobre las lecturas sucias cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento `READ UNCOMMITTED` en SQL Server en comparación con la implementación de Babelfish.


| Transacción 1 | Transacción 2 | `READ UNCOMMITTED` de SQL Server | `READ UNCOMMITTED` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`  |  `SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `UPDATE employee SET age=0;`  |  Actualización realizada correctamente.  |  Actualización realizada correctamente.  | 
|  Inactividad en la transacción  |  `INSERT INTO employee VALUES (4, 'D', 40);`  |  La inserción se ha realizado correctamente.  |  La inserción se ha realizado correctamente.  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  La transacción 1 puede ver los cambios no confirmados de la transacción 2.  |  Igual que `READ COMMITTED` en Babelfish. Los cambios no confirmados de la transacción 2 no son visibles en la transacción 1.   | 
|  Inactividad en la transacción  |  `COMMIT`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Ve los cambios efectuados por la transacción 2.  |  Ve los cambios efectuados por la transacción 2.  | 

## `READ COMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ COMMITTED`
<a name="babelfish-transaction.examples.com"></a>

La siguiente tabla proporciona detalles sobre el comportamiento de bloqueo de lectura y escritura cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento `READ COMMITTED` en SQL Server en comparación con la implementación de Babelfish.


| Transacción 1 | Transacción 2 | `READ COMMITTED` de SQL Server | `READ COMMITTED` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`  |  `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `UPDATE employee SET age=100 WHERE id = 1;`  |  Actualización realizada correctamente.  |  Actualización realizada correctamente.  | 
|  `UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`  |  Inactividad en la transacción  |  Paso bloqueado hasta que se confirme la transacción 2.  |  Los cambios en la transacción 2 aún no están visibles. Actualiza la fila con id=3.  | 
|  Inactividad en la transacción  |  `COMMIT`  |  La transacción 2 se confirma correctamente. La transacción 1 ahora está desbloqueada y recibe la actualización de la transacción 2.  |  La transacción 2 se confirma correctamente.   | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  La transacción 1 actualiza la fila con el id = 1.  |  La transacción 1 actualiza la fila con el id = 3.  | 

## `READ COMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ COMMITTED SNAPSHOT`
<a name="babelfish-transaction.examples.snapshot"></a>

La siguiente tabla proporciona detalles sobre el comportamiento de bloqueo de las filas recién insertadas cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento `READ COMMITTED SNAPSHOT` en SQL Server en comparación con la implementación de Babelfish `READ COMMITTED`.


| Transacción 1 | Transacción 2 | `READ COMMITTED SNAPSHOT` de SQL Server | `READ COMMITTED` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`  |  `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`  |  Ninguna  |  Ninguna  | 
|  `INSERT INTO employee VALUES (4, 'D', 40);`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `UPDATE employee SET age = 99;`  |  Paso bloqueado hasta que se confirme la transacción 1. La fila insertada está bloqueada por la transacción 1.  |  Se actualizaron tres filas. La fila recién insertada aún no está visible.  | 
|  `COMMIT`  |  Inactividad en la transacción  |  Confirmación realizada correctamente. La transacción 2 ahora está desbloqueada.  |  Confirmación realizada correctamente.  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  Las 4 filas tienen una age=99.  |  La fila con un id = 4 tiene un valor de antigüedad de 40, ya que la transacción 2 no la pudo ver durante la consulta de actualización. Las demás filas se actualizan a una age=99.   | 

## `REPEATABLE READ` de Babelfish en comparación con el nivel de aislamiento de SQL Server `REPEATABLE READ`
<a name="babelfish-transaction.examples.read"></a>

La siguiente tabla proporciona detalles sobre el comportamiento de bloqueo de lectura y escritura cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento `REPEATABLE READ` en SQL Server en comparación con la implementación de Babelfish `REPEATABLE READ`.


| Transacción 1 | Transacción 2 | `REPEATABLE READ` de SQL Server | `REPEATABLE READ` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  `UPDATE employee SET name='A_TXN1' WHERE id=1;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee WHERE id != 1;`  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  La transacción 2 se bloquea hasta que se confirme la transacción 1.  |  La transacción 2 se lleva a cabo con normalidad.   | 
|  `COMMIT`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  La actualización de la transacción 1 está visible.  |  La actualización de la transacción 1 no está visible.  | 
|  `COMMIT`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  ve la actualización de la transacción 1.  |  ve la actualización de la transacción 1.  | 

La siguiente tabla proporciona detalles sobre el comportamiento de bloqueo de lectura y escritura cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento `REPEATABLE READ` en SQL Server en comparación con la implementación de Babelfish `REPEATABLE READ`.


| Transacción 1 | Transacción 2 | `REPEATABLE READ` de SQL Server | `REPEATABLE READ` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Ninguna  |  Ninguna  | 
|  `UPDATE employee SET name='A_TXN1' WHERE id=1;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `UPDATE employee SET name='A_TXN2' WHERE id=1;`  |  Transacción 2 bloqueada.  |  Transacción 2 bloqueada.  | 
|  `COMMIT`  |  Inactividad en la transacción  |  La confirmación se ha realizado correctamente y la transacción 2 se ha desbloqueado.  |  La confirmación se ha realizado correctamente y la transacción 2 falló debido a un error de tipo “No se pudo serializar el acceso debido a una actualización simultánea”.  | 
|  Inactividad en la transacción  |  `COMMIT`  |  Confirmación realizada correctamente.  |  La transacción 2 ya se ha cancelado.  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  La fila con id=1 tiene name='A\$1TX2'.  |  La fila con id=1 tiene name='A\$1TX1'.  | 

La siguiente tabla proporciona detalles sobre el comportamiento de las lecturas fantasma cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento `REPEATABLE READ` en SQL Server en comparación con la implementación de Babelfish `REPEATABLE READ`.


| Transacción 1 | Transacción 2 | `REPEATABLE READ` de SQL Server | `REPEATABLE READ` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `INSERT INTO employee VALUES (4, 'NewRowName', 20);`  |  La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.  |  La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  La fila recién insertada está visible.  |  La fila recién insertada está visible.  | 
|  Inactividad en la transacción  |  `COMMIT`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  La nueva fila insertada por la transacción 2 está visible.  |  La nueva fila insertada por la transacción 2 no está visible.  | 
|  `COMMIT`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  La fila recién insertada está visible.  |  La fila recién insertada está visible.  | 

La siguiente tabla proporciona detalles sobre cuándo se ejecutan transacciones simultáneas y los diferentes resultados finales cuando se utiliza el nivel de aislamiento `REPEATABLE READ` en SQL Server en comparación con la implementación de Babelfish `REPEATABLE READ`.


| Transacción 1 | Transacción 2 | `REPEATABLE READ` de SQL Server | `REPEATABLE READ` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Ninguna  |  Ninguna  | 
|  `UPDATE employee SET age = 100 WHERE age IN (SELECT MIN(age) FROM employee);`  |  Inactividad en la transacción  |  La transacción 1 actualiza la fila con el id 1.  |  La transacción 1 actualiza la fila con el id 1.  | 
|  Inactividad en la transacción  |  `UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`  |  La transacción 2 está bloqueada porque la instrucción SELECT intenta leer las filas bloqueadas por la consulta UPDATE en la transacción 1.  |  La transacción 2 se realiza sin ningún bloqueo, ya que la lectura nunca se bloquea, la instrucción SELECT se ejecuta y, finalmente, la fila con el id = 3 se actualiza, ya que los cambios en la transacción 1 aún no están visibles.  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  Este paso se ejecuta después de que se haya confirmado la transacción 1. La fila con el id = 1 se actualiza con la transacción 2 del paso anterior y está visible aquí.  |  La fila con un id = 3 se actualiza mediante la transacción 2.  | 
|  `COMMIT`  |  Inactividad en la transacción  |  La transacción 2 ahora está desbloqueada.  |  Confirmación realizada correctamente.  | 
|  Inactividad en la transacción  |  `COMMIT`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Ambas transacciones ejecutan una actualización en la fila con un id = 1.  |  Las distintas filas se actualizan por las transacciones 1 y 2.  | 

## `SERIALIZABLE` de Babelfish en comparación con el nivel de aislamiento de SQL Server `SERIALIZABLE`
<a name="babelfish-transaction.examples.serialize"></a>

La siguiente tabla proporciona detalles sobre los bloqueos de rango cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento `SERIALIZABLE` en SQL Server en comparación con la implementación de Babelfish `SERIALIZABLE`.


| Transacción 1 | Transacción 2 | `SERIALIZABLE` de SQL Server | `SERIALIZABLE` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `INSERT INTO employee VALUES (4, 'D', 35);`  |  La transacción 2 se bloquea hasta que se confirme la transacción 1.  |  La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  Ninguna  |  Ninguna  | 
|  `COMMIT`  |  Inactividad en la transacción  |  La transacción 1 se confirma correctamente. La transacción 2 ahora está desbloqueada.  |  La transacción 1 se confirma correctamente.   | 
|  Inactividad en la transacción  |  `COMMIT`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  La fila recién insertada está visible.  |  La fila recién insertada está visible.  | 

La siguiente tabla proporciona detalles sobre cuándo se ejecutan transacciones simultáneas y los diferentes resultados finales cuando se utiliza el nivel de aislamiento `SERIALIZABLE` en SQL Server en comparación con la implementación de Babelfish `SERIALIZABLE`.


| Transacción 1 | Transacción 2 | `SERIALIZABLE` de SQL Server | `SERIALIZABLE` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `INSERT INTO employee VALUES (4, 'D', 40);`  |  Ninguna  |  Ninguna  | 
|  `UPDATE employee SET age =99 WHERE id = 4;`  |  Inactividad en la transacción  |  La transacción 1 se bloquea hasta que se confirme la transacción 2.  |  La transacción 1 se lleva a cabo sin ningún tipo de bloqueo.  | 
|  Inactividad en la transacción  |  `COMMIT`  |  La transacción 2 se confirma correctamente. La transacción 1 ahora está desbloqueada.  |  La transacción 2 se confirma correctamente.  | 
|  `COMMIT`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  La fila recién insertada es visible con un valor de age = 99.  |  La fila recién insertada es visible con un valor de age = 40.  | 

En la siguiente tabla se proporcionan detalles cuando realiza la operación `INSERT` en una tabla con una restricción única. Muestra los resultados observados al utilizar el nivel de aislamiento `SERIALIZABLE` en SQL Server en comparación con la implementación de Babelfish `SERIALIZABLE`.


| Transacción 1 | Transacción 2 | `SERIALIZABLE` de SQL Server | `SERIALIZABLE` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `INSERT INTO employee VALUES (4, 'D', 40);`  |  Ninguna  |  Ninguna  | 
|  `INSERT INTO employee VALUES ((SELECT MAX(id)+1 FROM employee), 'E', 50);`  |  Inactividad en la transacción  |  La transacción 1 se bloquea hasta que se confirme la transacción 2.  |  La transacción 1 se bloquea hasta que se confirme la transacción 2.  | 
|  Inactividad en la transacción  |  `COMMIT`  |  La transacción 2 se confirma correctamente. La transacción 1 ahora está desbloqueada.  |  La transacción 2 se confirma correctamente. La transacción 1 abortada por un error de tipo “el valor clave duplicado infringe una restricción única”.  | 
|  `COMMIT`  |  Inactividad en la transacción  |  La transacción 1 se confirma correctamente.  |  La confirmación de la transacción 1 falla y no se pudo serializar el acceso debido a las dependencias de lectura o escritura entre las transacciones.  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  se inserta la fila (5, 'E', 50).  |  Solo existen 4 filas.  | 

En Babelfish, las transacciones simultáneas que se ejecutan con nivel de aislamiento Serializable fallarán y generarán un error de anomalía de serialización si la ejecución de estas transacciones no es coherente con todas las posibles ejecuciones en serie (una a la vez) de esas transacciones.

Las siguientes tablas proporcionan detalles sobre la anomalía de la serialización cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento `SERIALIZABLE` en SQL Server en comparación con la implementación de Babelfish `SERIALIZABLE`.


| Transacción 1 | Transacción 2 | `SERIALIZABLE` de SQL Server | `SERIALIZABLE` de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  `UPDATE employee SET age=5 WHERE age=10;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  La transacción 2 se bloquea hasta que se confirme la transacción 1.  |  La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.  | 
|  Inactividad en la transacción  |  `UPDATE employee SET age=35 WHERE age=30;`  |  Ninguna  |  Ninguna  | 
|  `COMMIT`  |  Inactividad en la transacción  |  La transacción 1 se confirma correctamente.  |  La transacción 1 se confirma primero y puede confirmarse correctamente.  | 
|  Inactividad en la transacción  |  `COMMIT`  |  La transacción 2 se confirma correctamente.  |  La confirmación de la transacción 2 falla con un error de serialización, se revierte toda la transacción. Vuelva a intentar la transacción 2.  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Los cambios de ambas transacciones son visibles.  |  La transacción 2 se revirtió. Solo se ven los cambios en la transacción 1.  | 

En Babelfish, la anomalía de serialización solo es posible si todas las transacciones simultáneas se ejecutan en el nivel de aislamiento `SERIALIZABLE`. En la siguiente tabla, tomemos el ejemplo anterior, pero establezcamos la transacción 2 en el nivel de aislamiento `REPEATABLE READ`.


| Transacción 1 | Transacción 2 | Niveles de aislamiento de SQL Server | Niveles de aislamiento de Babelfish | 
| --- | --- | --- | --- | 
|  `BEGIN TRANSACTION`  |  `BEGIN TRANSACTION`  |  Ninguna  |  Ninguna  | 
|  `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`  |  `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`  |  Ninguna  |  Ninguna  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  `UPDATE employee SET age=5 WHERE age=10;`  |  Inactividad en la transacción  |  Ninguna  |  Ninguna  | 
|  Inactividad en la transacción  |  `SELECT * FROM employee;`  |  La transacción 2 se bloquea hasta que se confirme la transacción 1.  |  La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.  | 
|  Inactividad en la transacción  |  `UPDATE employee SET age=35 WHERE age=30;`  |  Ninguna  |  Ninguna  | 
|  `COMMIT`  |  Inactividad en la transacción  |  La transacción 1 se confirma correctamente.  |  La transacción 1 se confirma correctamente.  | 
|  Inactividad en la transacción  |  `COMMIT`  |  La transacción 2 se confirma correctamente.  |  La transacción 2 se confirma correctamente.  | 
|  `SELECT * FROM employee;`  |  Inactividad en la transacción  |  Los cambios de ambas transacciones son visibles.  |  Los cambios de ambas transacciones son visibles.  |