13-12-2017, 09:17
13-12-2017, 10:56
Resolución personal, nada verificado (?):
Creo que todo lo que tomaron fueron de finales previos. Suerte!
Spoiler: Mostrar
1.a) V (tengo mis dudas igual).
1.b) F.
2.a) y 2.b) están en los apuntes de teoría, nada loco (?
3.a) es la B, interbloqueo. La razón es porque cuando ambas transacciones hacen un SELECT, ambas "lockean" la tabla para sí mismas. Como tienen nivel de aislamiento serializable, eso significa que ninguna otra transacción va a poder hacer insert/update/delete (pero sí se pueden hacer SELECT's...por eso mismo cuando la transacció B, en el momento 2, hace un select lo hace sin problema alguno). Luego cuando la transacción A intenta hacer un UPDATE en el tiempo 3, no puede porque está lockeado por la transacción B. Y lo mismo ocurre en la transacción B en el tiempo 4. Ergo, deadlock.
3.b) Lo tomaron en la fecha anterior a esta jeje.
1.b) F.
2.a) y 2.b) están en los apuntes de teoría, nada loco (?
3.a) es la B, interbloqueo. La razón es porque cuando ambas transacciones hacen un SELECT, ambas "lockean" la tabla para sí mismas. Como tienen nivel de aislamiento serializable, eso significa que ninguna otra transacción va a poder hacer insert/update/delete (pero sí se pueden hacer SELECT's...por eso mismo cuando la transacció B, en el momento 2, hace un select lo hace sin problema alguno). Luego cuando la transacción A intenta hacer un UPDATE en el tiempo 3, no puede porque está lockeado por la transacción B. Y lo mismo ocurre en la transacción B en el tiempo 4. Ergo, deadlock.
3.b) Lo tomaron en la fecha anterior a esta jeje.
Creo que todo lo que tomaron fueron de finales previos. Suerte!
12-02-2019, 05:02
(13-12-2017 10:56)Omnipresent escribió: [ -> ]Resolución personal, nada verificado (?):
Spoiler: Mostrar1.a) V (tengo mis dudas igual).
1.b) F.
2.a) y 2.b) están en los apuntes de teoría, nada loco (?
3.a) es la B, interbloqueo. La razón es porque cuando ambas transacciones hacen un SELECT, ambas "lockean" la tabla para sí mismas. Como tienen nivel de aislamiento serializable, eso significa que ninguna otra transacción va a poder hacer insert/update/delete (pero sí se pueden hacer SELECT's...por eso mismo cuando la transacció B, en el momento 2, hace un select lo hace sin problema alguno). Luego cuando la transacción A intenta hacer un UPDATE en el tiempo 3, no puede porque está lockeado por la transacción B. Y lo mismo ocurre en la transacción B en el tiempo 4. Ergo, deadlock.
3.b) Lo tomaron en la fecha anterior a esta jeje.
Creo que todo lo que tomaron fueron de finales previos. Suerte!
La 3a) no puede ser B, Solo en el caso que la Transaccion B en el tiempo 5 sea commit y no rollback ,puede ser interbloqueo
19-02-2020, 00:18
Aporto sobre la pregunta practica 1 sobre los "Deadlocks que se pueden dar en ISOLATION LEVEL SERIALIZABLE" que va en linea de lo que puso Omnipresent.
https://stackoverflow.com/questions/3902...ncy-issues
https://stackoverflow.com/questions/2734...n-deadlock
https://stackoverflow.com/questions/3902...ncy-issues
https://stackoverflow.com/questions/2734...n-deadlock
19-02-2020, 10:12
Del ejercicio 3.a) estoy bastante seguro que la respuesta es 1
Hago un paso a paso:
Tiempo 1 => TA toma lockeo de la tabla product con clave id = 1
Tiempo 2 => TB queda bloqueado ya que, por estar en SERIALIZABLE, quiere hacer un select el cual implica lockear la tabla. Como ya existe un lock ( lo tiene TA) se queda bloqueado esperando.
Tiempo 3 => TA hace el update sin problemas ya que posee el lock
Tiempo 5 => commitea la transaccion
Tiempo 6 => se libera el lock, lo toma TB, hace el select, hace el update y rollbackea.
Resultado => la tabla product con id=1 queda con detalle = X.
Sumo algo mas,
para que se de interbloqueo(deadlock) se tiene que dar : 2 TRANSACCIONES ( o mas) , las cuales necesitan 2 recursos o mas. En este caso, son 2 transacciones peleando por un mismo recurso ( tabla product con clave id = 1 ). El resultado va a ser que una se va a ejecutar antes que la otra ( dependiendo quien tome el lock primero ).
sldos
Hago un paso a paso:
Tiempo 1 => TA toma lockeo de la tabla product con clave id = 1
Tiempo 2 => TB queda bloqueado ya que, por estar en SERIALIZABLE, quiere hacer un select el cual implica lockear la tabla. Como ya existe un lock ( lo tiene TA) se queda bloqueado esperando.
Tiempo 3 => TA hace el update sin problemas ya que posee el lock
Tiempo 5 => commitea la transaccion
Tiempo 6 => se libera el lock, lo toma TB, hace el select, hace el update y rollbackea.
Resultado => la tabla product con id=1 queda con detalle = X.
Sumo algo mas,
para que se de interbloqueo(deadlock) se tiene que dar : 2 TRANSACCIONES ( o mas) , las cuales necesitan 2 recursos o mas. En este caso, son 2 transacciones peleando por un mismo recurso ( tabla product con clave id = 1 ). El resultado va a ser que una se va a ejecutar antes que la otra ( dependiendo quien tome el lock primero ).
sldos
19-02-2020, 22:59
Sumo un voto para lo que dice nanohueso, aportando la definicion de la catedra
SERIALIZABLE:garantiza que una transacción recuperará exactamente los mismos datos cada vez que repita una operación de lectura (es decir, la misma sentencia SELECT con la misma cláusula WHERE devolverá el mismo número de filas, luego no se podrán insertar filas nuevas en el rango cubierto por la WHERE, etc. -se evitarán laslecturas fantasma), aunque para ello aplicará un nivel de bloqueo que puede afectar a los demás usuarios en los sistemas multiusuario (realizará un bloqueo de un rango de índice -conforme a la cláusula WHERE -y si no es posible bloqueará toda la tabla). Evita los problemas de las lecturas sucias (dirty reads), de las lecturas no repetibles (non repeatablereads), y de las lecturas fantasma (phantomreads).
Para mi este es el caso que se da ya que la transaccion A realiza primero el SELECT y le "gana de mano" a la transaccion B, que intenta hacer lo mismo.
SERIALIZABLE:garantiza que una transacción recuperará exactamente los mismos datos cada vez que repita una operación de lectura (es decir, la misma sentencia SELECT con la misma cláusula WHERE devolverá el mismo número de filas, luego no se podrán insertar filas nuevas en el rango cubierto por la WHERE, etc. -se evitarán laslecturas fantasma), aunque para ello aplicará un nivel de bloqueo que puede afectar a los demás usuarios en los sistemas multiusuario (realizará un bloqueo de un rango de índice -conforme a la cláusula WHERE -y si no es posible bloqueará toda la tabla). Evita los problemas de las lecturas sucias (dirty reads), de las lecturas no repetibles (non repeatablereads), y de las lecturas fantasma (phantomreads).
Para mi este es el caso que se da ya que la transaccion A realiza primero el SELECT y le "gana de mano" a la transaccion B, que intenta hacer lo mismo.