Seguimos buscando a Arshak. Ayudanos compartiendo!
Encuesta no oficial de docentes
Resultados de la encuesta no oficial de docentes
Probaste el SIGA Helper?

Donar $100 Donar $200 Donar $500 Donar mensualmente


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
[Aporte] Final GDD 12/12/2017
Autor Mensaje
gabrielarce Sin conexión
Militante
Benditos finales..
***

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 97
Agradecimientos dados: 56
Agradecimientos: 18 en 10 posts
Registro en: Jan 2010
Mensaje: #1
[Aporte] Final GDD 12/12/2017 Finales Gestión de Datos
Gente! les paso el final de ayer..

Saludos!


Archivo(s) adjuntos
.pdf  final gdd 12.12.2017[1].pdf (Tamaño: 356,04 KB / Descargas: 544)
(Este mensaje fue modificado por última vez en: 13-12-2017 09:25 por gabrielarce. Razón de la edición: Aporte)
13-12-2017 09:17
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] gabrielarce recibio 6 Gracias por este post
chrisgel15 (13-12-2017), CarooLina (13-12-2017), vim (17-12-2017), Smitten1994 (02-12-2018), pablit (15-08-2019), DrWily (30-11-2019)
Omnipresent Sin conexión
Profesor del Modulo A
The Winter is Coming...
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 215
Agradecimientos dados: 51
Agradecimientos: 94 en 61 posts
Registro en: Sep 2014
Mensaje: #2
RE: [Aporte] Final GDD 12/12/2017
Resolución personal, nada verificado (?):
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.

Creo que todo lo que tomaron fueron de finales previos. Suerte!
(Este mensaje fue modificado por última vez en: 13-12-2017 10:59 por Omnipresent.)
13-12-2017 10:56
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Omnipresent recibio 1 Gracias por este post
CarooLina (13-12-2017)
Soy Sin conexión
Empleado de Fotocopiadora
:)
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 39
Agradecimientos dados: 36
Agradecimientos: 27 en 13 posts
Registro en: Jan 2019
Mensaje: #3
RE: [Aporte] Final GDD 12/12/2017
(13-12-2017 10:56)Omnipresent escribió:  Resolución personal, nada verificado (?):
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.

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
12-02-2019 05:02
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Mauro_bilo Sin conexión
Campeon del cubo Rubik
Tool
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 120
Agradecimientos dados: 138
Agradecimientos: 36 en 20 posts
Registro en: Sep 2010
BlogSpot Facebook LinkedIn
Mensaje: #4
RE: [Aporte] Final GDD 12/12/2017
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
(Este mensaje fue modificado por última vez en: 19-02-2020 00:20 por Mauro_bilo.)
19-02-2020 00:18
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
nanohueso Sin conexión
Profesor del Modulo A
Thats what she said
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 234
Agradecimientos dados: 239
Agradecimientos: 24 en 16 posts
Registro en: Feb 2012
Mensaje: #5
RE: [Aporte] Final GDD 12/12/2017
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
(Este mensaje fue modificado por última vez en: 19-02-2020 10:15 por nanohueso.)
19-02-2020 10:12
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
chrisgel15 Sin conexión
Profesor del Modulo A
De Racing, Vago y Atorrante
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 237
Agradecimientos dados: 428
Agradecimientos: 107 en 55 posts
Registro en: Jul 2010
Facebook
Mensaje: #6
RE: [Aporte] Final GDD 12/12/2017
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.
19-02-2020 22:59
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 1 invitado(s)



    This forum uses Lukasz Tkacz MyBB addons.