el 3.b) claramente al ser read uncommited permite todas las mezclas, asique queda
(2,0)
sobre el 3.a) es una poronga
pero si no interpreto mal..
queda (2, 0) para la transaccion de la izquierda, y (2, 4) para la transaccion de la derecha (lo que devuelve el select)
esto es porque
- se ejecutan ambos selects. Ambos leen 2
- se ejecuta el update la transacción de la izquierda, que tiene un isolation level de Read Commited. Esto implica que lee el 2, le resta 2, y todo hermoso, quedando todos los valores updateados a 0.
- se ejecuta el update de la transacción de la derecha, que tiene un isolation level de Serializable. En este punto, el bloqueo exclusivo de la lectura del update anterior ya termino, por lo que no da deadlock*, y genera un bloque exclusivo para hacer el update. El tema es que al ser serializable, el update requiere leer de valor (porque usa el valor que esta guardado en la tabla para setear el nuevo), y ya leyo con el select anterior que era 2.. asique hace update valor = 2 * 2.
y pisa el update anterior!
Luego, la query de la izquierda lee el valor = 0 (porque lee valores commiteados, pero el serializable aun no commiteo) y el de la derecha lee valor = 4 (tener en cuenta que leer valores commiteados o no es para cuando los cambios vienen de afuera. Sino sql perderia sentido si hago un update y sigo leyendo los valores originales!)
y en la tabla, finalmente queda el valor (2, 4) porque es el ultimo update corrido
* igual es tramposo en esto, porque si ambos procesos tuvieran una conexion distinta cada uno, si daria deadlock. El deadlock no se produce porque se asume que ambos procesos tienen la misma conexion, pero en la realidad probablemente cada transacción tenga su conexion y de ahi de deadlock (porque al escribir en una transaccion con ese isolation level bloquea esa tabla escrita y desde afuera no la podes leer y te quedas esperando q se libere, y el otro proceso espera q termine la lectura para seguir --> deadlock!); para tener en cuenta en la realidad (y sobre todo, si lo prueban en sql server donde cada ventanita new query corre como una conexion distinta, entonces magicamente se les va a bloquear y pareciera que la teoria vista se cae pero no! no es asi jaja)
(19-02-2013 11:36)javibishop escribió: [ -> ]El ejericio, por lo que vi y probe, cuando corre la transaccion serializable, bloquea todo, o sea, bloquea la otra transaccion, por ende :
hace todo la transaccion 2 y cuando termina, ejecuta la 1, lo que si se hace de la 1 es el primer select, ya que al paso siguiente la trans2 ejecuta un select y ahi bloquea entonces desde ahi t1 queda en espera que finalice t2 ya que si proxima a ejecutar en t1 es un update. si fuera un select me devolveria el dato original ya que la trans serializable garantiza lecturas repetidas, no fantasmas y no sucias.
no, porque estas cambiando el orden de ejecucion. De ultima seria un deadlock, pero no podes alterar el orden. Te dicen que se corren asi, no que hay 2 procesos con esas instrucciones, adivinar como se corren y que devuelven
.gif "=)")
?