Les dejo el Final de GDD del 26/05/14.

Saludos.

Algún alma caritativa que haga los ejercicios prácticos??

revivo este final , en el punto de aislmaiento , me quedo que haria solamente la tran1 ya que bloquea por completo el serializable y como tran1 es la que empieza a leer ( select) entonces solamente se ejecutan sus instrucciones hasta su commit , por ende el id queda seteado en X

esta bien pensando?

Una vez que comittea la tran1, ahí hace el select y todo lo demás la t2. Pero como hace rollback queda todo como lo dejo la tran1. Asique queda en x

alguien sabe como es la ultima query? yo le agregue un
ORDER BY detalle desc
pero es medio raro, porque si a la columna que muestra el select le pones una descripcion, o sea le pones al ISNULL(sarasa) as detalle_registro, ya no te ordena los nulls al final, te los deja por el medio... Estoy pensando otra forma de hacerlo igual, yo calculo que es con un sub select

mobyer , me parece que no es como decis y llegas a la x ; osea una vez que hace el commit termina ahi , y t2 no hace nada por mas que este el roolback , ya que su tiempos ya pasaron , si hubiesen estado dsp del coomit de t1 podria hacer cualquier cosa.

en resumen para mi queda asi porque bloquea todo el t1 y una vez que hace el commit termina todo ahi ya que no hay mas tiempo. ( osea no es que hace el commit y luego pasa a t2) nose si me explico

ya lo hice el ultimo, una forma bien seria "ORDER BY (SELECT COUNT(p1.descripcion) FROM producto p1 WHERE p1.id = p.id)" p es la referencia a la tabla externa de producto

Incluyo un poco de lo teorico pero con algunas dudas, si ven algun error chiflen

1.a. V
1.b. F

2.a Se me ocurre Plan de ejecución, indices algo mas??

Hola yo para el 3)b) lo pense asi:

select id, detalle
from producto
where detalle is not null
union all
select id, isnull(detalle, 'sin descripcion)'
from producto
where detalle is null

el union all los ordena por id y de esta forma pone los que tienen null abajo de todos.

Saludos

Respecto del 3a, mi opinión es que da deadlock y si no me equivoqué al probarlo con un codigo similar estoy en lo correcto.

La transaccion A hace un select con lo que bloquea updates e inserts en ese sector de la tabla.
después la transacción b también hace un select. El select no es un update ni un insert, por lo cual el select sí lo ejecuta (ya que la transacción A había hecho un select y no un update, por lo que no necesita esperar a que se comiteen los cambios paa ejecutar el select... porque aún no hay cambios)
Al hacer ese select la transacción B también bloquea ese cacho de tabla y dice "che, a mí esto no me lo cambien que ya lo empecé a leer"
Entocnes cuanto Tran A trata de hacer un update, se queda trabada porque Tran B le bloqueó el pedazod e tabla. Y lo mismo pasa al revés, al hacer Tran B el update en el instante 4, se lockea esperando que A le libere lo que habia bloqueado en un principio. Ergo las dos bloquearon un cacho de tabla y las dos quieren modificarlo, y ninguna deja a la otra => Deadlock.

 

set transaction isolation level serializable



begin tran ta

select * from cuenta

waitfor delay '000:000:10'

update cuenta set saldo = 10 where id_cuenta=2

commit tran ta



set transaction isolation level serializable



begin tran tb

select * from cuenta

waitfor delay '000:000:11'

update cuenta set saldo = 30 where id_cuenta=2

rollback tran tb

[code=plain]

Ese es el código con el que lo probé, creo que aplica. Mató a la tA por deadlock y de la B me mostró el resultado del select.

Bueno si hay algo en lo que me equivoqué, disculpas!

Yo coincido con lo que dijo mobyer más arriba.

Vos en el código que mostraste no estás garantizando que el primer select de la tranA se realice antes que el select de la tranB.

Además, no le veo el sentido de que quede en deadlock si están en serializable, ya que los pone en serie.. Qué se quedaría esperando tranA? Debería correr todo de una.

Saludos!

En mi pc lo corrí en orden de forma tal de que se ejecutara ese select primero.

Es decir, corri la transacción A y después de unos segundos (suponiendo que ya habría entrado en el waitfordelay) le di run a la tansacción 2... (las corrí en pestañas de queries distintas) Supuse que eso era garantía suficiente de que se estaban ejecutando en el orden que digo porque en el apunto los ejemplos que da en codigo para probar son similares... de todas formas puedo estar equivocado.

Y es verdad lo que decís de que no tiene mucho sentido... pero el deadlock pasó posta jaja, si no fue por lo que digo no sé por qué fue.

Si alguien tiene la posta que aclare y justifique jaja

Tizi Perdon pero, en el ultimo ejercicio... no entiendo cual es el comportamiento extraño que tenes poniendo un order by detalle desc... yo lo hice y me lo ordeno bien...

tengo la misma duda que el de arriba...


Alguno sabe?

Nacho14 coolerking , lo que dice Tizi es que si le agregas un alias a la columna que se le aplica la funcion isNull y ordenas por el verdadero nombre de la columna, no pone los NULL abajo de todo:

Select id, isNull(detalle,'sin descripcion') as el_detalle
from producto
order by detalle desc

La solucion seria ordenar por la columna por el alias:

Select id, isNull(detalle,'sin descripcion') as el_detalle
from producto
order by el_detalle

Ojo que no corre el order by desc en este caso. Directamente te manda los null abajo.