Consulta final de febrero 2010

[Matias Corbanini]

3) Dada la tabla prueba

CREATE TABLE prueba( col1 int NOT NULL ) ;

Sabiendo que la tabla se encuentra creada y vacía responda que sucede
al ejecutar los siguientes procesos en paralelo en sesiones
diferentes:

Proceso 1

begin transaction
declare @a as int
declare @b as int
select @a = count(*) from prueba
select @b = count(*) from prueba
commit;

Proceso 2

begin transaction
insert into prueba (col1) (select max(col1)+1 from prueba)
commit;


Elija la opción correcta y justifíquela

a)La variable a y b siempre son iguales.
b)La variable a y b nunca son iguales.
c)El resultado de a y b depende de cómo se ejecuten los movimientos
d)No hay suficiente información para conocer que valores puede tomar a
y b.
e)Ninguna de las anteriores.


----------------------

Bueno me estaba quemando un poco la cabeza con esto, empece a buscar
sobre el tema de la concurrencia de transacciones, y vi que sql server
aplica el isolation level en "read commited" por default..
Segun dice en el apunte de T-Sql, seria:

READ COMMITED:

especifica que se mantengan los bloqueos compartidos mientras se leen
datos apra evitar lecturas no actualizadas, pero se pueden modificar
los datos antes del final de la transaccion, lo que provoca lecturas
no repetibles o datos fantasma.


Viendo si con esa definicion, deberia ser el punto a) o c), decidi
crear la tabla en el sql y ejecutar la transaccion que hace el INSERT
y me tiro error diciendo que no se puede insertar un NULL.
Y claro, si se especifica que la columna es NOT NULL, es logico,
entonces con ese resultado, la transaccion tiraria error y no se
insertaria nada, por lo tanto las variables a y b, siempre son
iguales.

Estan de acuerdo conmigo??

Ahora, sin tener en cuenta que se genera ese error, si la tabla
tuviese cargado cualquier numero, y el insert no daria error,
entonces, con cual de las opciones se quedarian y porque?

Gracias!!!
Saludos.
Matias.

[Rodrigo Fernandez]

Hola Matias, por lo que entiendo de las transacciones, creo que la respuesta es la (a), pues una transacción es atómica.

--
RoDRigo

Ideas Libres

[Matias Corbanini]

Si pero, la justificacion seria porque la transaccion del INSERT
genera un error, por lo tanto no se inserta nada en la tabla, que la
otra transaccion va a leer.
En el caso que la transaccion inserte datos, antes de que se hagan los
select en la otra transaccion, entre medio de los select, o despues...
creo que leeria cosas diferentes, proq una cosa es que sea atomica y
otra cosa es que 2 transacciones lean o inserten o actualicen de una
tabla al mismo tiempo.

On 6 feb, 20:03, Rodrigo Fernandez <rdr....@gmail.com> wrote:
> Hola Matias, por lo que entiendo de las transacciones, creo que la respuesta
> es la (a), pues una transacción es atómica.
>
> El 6 de febrero de 2011 19:52, Matias Corbanini

> <mcorbaninica...@gmail.com>escribió:

> Ideas Libres <http://www.idlibre.com.ar/>

[Rodrigo Fernandez]

Pero al ser las transacciones operaciones atomicas donde se toman recursos y no se liberan hasta terminar, al hacer select @a = count(*) from prueba el recurso que es la tabla prueba ya queda tomado por la transacción y la libera cuando termina la transacción, entonces los inserts o update sobre la tabla se harían justo antes del primer select y despues del commit.

Suponiendo que lo que escribí esta bien y más allá del error del segundo proceso, los valores de a y b seguirían siendo iguales pues si la tabla está vacia el count daría 0.

--
RoDRigo

Ideas Libres

[Matias Corbanini]

Gracias por la info!!!

en el ultimo parrafo que escribiste, tambien se podria dar que se haga
el insert primero, antes que el select, entonces se bloquea la
transaccion que hace los select hasta despues del commit de la
transaccion que hace el insert, y los count del select den 1 y
seguirian siendo los mismos valores para a y b.... no?

On 6 feb, 20:37, Rodrigo Fernandez <rdr....@gmail.com> wrote:
> Pero al ser las transacciones operaciones atomicas donde se toman recursos y

> no se liberan hasta terminar, al hacer *select @a = count(*) from prueba* el

> recurso que es la tabla prueba ya queda tomado por la transacción y la
> libera cuando termina la transacción, entonces los inserts o update sobre la
> tabla se harían justo antes del primer select y despues del commit.
>
> Suponiendo que lo que escribí esta bien y más allá del error del segundo
> proceso, los valores de a y b seguirían siendo iguales pues si la tabla está
> vacia el count daría 0.
>
> El 6 de febrero de 2011 20:08, Matias Corbanini

> <mcorbaninica...@gmail.com>escribió:

> Ideas Libres <http://www.idlibre.com.ar/>

[Rodrigo Fernandez]

Claro

--
RoDRigo

Ideas Libres