Yo también tengo dudas en el 3a con las dos versiones, para mi terminaba en (2,4)
Sólo por el hecho en que ambas comienzan con un set isolation level, por lo cual la serializable va a bloquear todo lo que use


Votemos..... (?)

Alguien que pueda confirmar como es?

Hice las pruebas con estas sentencias:

 

set transaction isolation level read committed 

begin tran

select * from prueba where numero=2

WAITFOR DELAY '000:00:5'

update prueba set valor =valor -2 where numero=2

WAITFOR DELAY '000:00:05'

select * from prueba where numero=2

commit transaction

 

set transaction isolation level serializable

begin tran

WAITFOR DELAY '000:00:03'

select * from prueba where numero=2

WAITFOR DELAY '000:00:05'

update prueba set valor=valor*2 where numero=2

select * from prueba where numero=2

commit transaction

Me da que el resultado final es (2,2) y es lo que yo a ojo habia intuido en un principio pero no estoy seguro de como justificarla:
- Si poner que T1 se bloquea porque como T2 en el tiempo 4 hace un select de ese registro y es serializable, bloquea el registro
- O que, T1 en el tiempo 4 espera a que T2 haga el commit por su condicion de read commited

(27-02-2015 12:15)p3rch4 escribió:  Me da que el resultado final es (2,2) y es lo que yo a ojo habia intuido en un principio pero no estoy seguro de como justificarla:
- Si poner que T1 se bloquea porque como T2 en el tiempo 4 hace un select de ese registro y es serializable, bloquea el registro
- O que, T1 en el tiempo 4 espera a que T2 haga el commit por su condicion de read commited

3a)
Usé tus scripts (que de paso, están bien planteados) y si se fijan en los resultados, todos los selects de la Transacción 1 dan (2,2), mientras que en la Transacción 2 primero da (2,2) y en el último (2,4)... Sin embargo el resultado final es (2,2).

Lo que saco como deducción es que la transacción 1 se "frena" cuando llega al UPDATE, porque el primer SELECT de la Transacción 2 "bloquea" el mismo rango de registros que usa el UPDATE. Entonces la transacción 2 sigue su recorrido, se actualizan los valores a (2,4) (eso es lo que muestra el último select de T2) y se hace el Commit. Recién ahí se libera T1 y hace su UPDATE, actualizando el registro a (2,2) (lo que muestra el último select de T1). Se commitea T1 y fin del ejercicio.

3b)
También chequeado con los scripts.
Como ambas transacciones son READ UNCOMMITED, es como si las transacciones no existieran y por ende todo se ejecutara a la vez.
Es lo mismo que si en vez de dos "hilos" de ejecución tengamos uno sólo que haga lo siguiente:

 

set transaction isolation level read uncommitted 

begin tran

	select * from TablaPrueba where numero = 2

	select * from TablaPrueba where numero = 2

	update TablaPrueba set valor = valor - 2 where numero=2

	update TablaPrueba set valor=valor*2 where numero=2

	select * from TablaPrueba where numero = 2

commit transaction

El 3A queda (2,2) por lo siguiente

   

El 3B queda (2,0) por lo siguiente