Donar $20 Donar $50 Donar $100 Donar mensualmente
 


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
Consulta final de gestion de datos
Autor Mensaje
roman1981 Sin conexión
Profesor del Modulo A
Sin estado :(
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 260
Agradecimientos dados: 0
Agradecimientos: 15 en 8 posts
Registro en: Nov 2010
Mensaje: #1
Consulta final de gestion de datos Finales Gestión de Datos
Hola..adjunto un ejercicio de final de gestion de datos para ver si me pueden dar una mano porque no lo pude sacar.
Yo presumo que dado el orden en el que llegan las sentencias, al momento de ejecutarse el insert de la sesion 2 se produce un bloqueo exclusivo de lectura y escritura y hasta despues del tiempo 6 no se podra ejecutar nada desde la sesion1 pero si desde la sesion 2 se puede
acceder a ambas tuplas. Lo que si no se porque hay que aclarar en que motor se basa.


Archivo(s) adjuntos Imagen(es)
   
(Este mensaje fue modificado por última vez en: 13-07-2015 08:51 por roman1981.)
12-07-2015 18:47
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
roman1981 Sin conexión
Profesor del Modulo A
Sin estado :(
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 260
Agradecimientos dados: 0
Agradecimientos: 15 en 8 posts
Registro en: Nov 2010
Mensaje: #2
RE: Consulta final de gestion de datos
Gente...revivo el post para ver si algun alma caritativa me da una mano.
13-07-2015 08:51
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
rod77 Sin conexión
Presidente del CEIT
:o
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.079
Agradecimientos dados: 130
Agradecimientos: 399 en 176 posts
Registro en: Mar 2011
Mensaje: #3
RE: Consulta final de gestion de datos
Creo, que si se ejecuta entre el tiempo 5 y 6, solo va a ver el (1,1). ya que la sesión 1 al no tener un begin y commit, cuando se hace el insert, se inserta automaticamente. En cambio el otro queda a la espera del commit..
---------------

Aca tenes un post dedicado a Isolation Levels:
http://www.utnianos.com.ar/foro/tema-apo...ion-levels
(Este mensaje fue modificado por última vez en: 13-07-2015 09:45 por rod77.)
13-07-2015 09:44
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
roman1981 Sin conexión
Profesor del Modulo A
Sin estado :(
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 260
Agradecimientos dados: 0
Agradecimientos: 15 en 8 posts
Registro en: Nov 2010
Mensaje: #4
RE: Consulta final de gestion de datos
No entiendo en que me cambia la ejecucion por no tener un begin y un commit la sesion1 . Se ve que la sesion1 no es una transaccion y en consecuencia no realiza bloqueos. Podras detallarme un poco mejor que es lo que sucede ? gracias.
13-07-2015 11:01
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
fede333lago Sin conexión
Empleado de Fotocopiadora
Sin estado :(
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 37
Agradecimientos dados: 8
Agradecimientos: 37 en 12 posts
Registro en: Dec 2013
Mensaje: #5
RE: Consulta final de gestion de datos
Si no me equivoco podrías poner otra transacción entre 5 y 6 con nivel read uncommited que no establece ningún tipo de lock para hacer un select (si para un insert), con lo cual podrías leer los datos de la tabla a pesar de estar siendo bloqueada por la transacción original.
14-07-2015 00:02
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
roman1981 Sin conexión
Profesor del Modulo A
Sin estado :(
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 260
Agradecimientos dados: 0
Agradecimientos: 15 en 8 posts
Registro en: Nov 2010
Mensaje: #6
RE: Consulta final de gestion de datos
Mirá...despues de leer teoria y la explicacion que hay en wikipedia, una transaccion repeateable read al hacer un select produce bloqueos de lectura. En consecuencia la sesion2 al hacer el select bloquea la lectura de toda la tabla t1 hasta que haga commit. Me parece que hasta que la sesion2 no haga commit ninguna otra sesion va a poder leer esa tabla. Inclusive la sesion1 ni siquiera podra hacer el select. puede ser ?
(Este mensaje fue modificado por última vez en: 14-07-2015 08:51 por roman1981.)
14-07-2015 08:46
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
roman1981 Sin conexión
Profesor del Modulo A
Sin estado :(
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 260
Agradecimientos dados: 0
Agradecimientos: 15 en 8 posts
Registro en: Nov 2010
Mensaje: #7
RE: Consulta final de gestion de datos
Gente,,,si alguno me da una mano con este ejercicio??
(Este mensaje fue modificado por última vez en: 14-07-2015 13:40 por roman1981.)
14-07-2015 10:56
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Chocolito Sin conexión
Empleado de Fotocopiadora
de sitio.
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 41
Agradecimientos dados: 26
Agradecimientos: 8 en 5 posts
Registro en: Apr 2010
Mensaje: #8
RE: Consulta final de gestion de datos
Lo del motor de la DB es para ver en qué te basas para responder.

Yo primero diría que considero que el begin y el commit de la sesión uno están por fuera de estos tiempos, considerándola una transacción. Después, basandome en lo que dice acá sobre shared y exclusive locks (https://technet.microsoft.com/en-us/libr....80).aspx) diría que al ser una transacción Repeteable read, esta bloquearía cualquier cosa que lee hasta terminar (shared lock). El fin de esta transacción no se ve, pero el shared lock no prohíbe insertar datos, sino que prohíbe modificar el dato: parece ser uno de los ejemplos de lectura fantasma propios del repeteable read: donde no se permite modificar un valor leído, pero tampoco se prohíbe insertar valores o consultar por valores en otro rango de la tabla.

Por otro lado, no hay exclusive lock, porque en ningún momento hay un update que lo genere. Esto nos porhibiría leer los valores insertados. Pero dado que no hay ni exclusive lock, ni se propone modificar los datos, la respuesta a la consigna sería que si, que podría haber una transacción que pudiera leer esos datos. Entiendo que ninguna de las cosas se lo prohibiría.

Shared lock prohíbe modificar el dato; Exclusive lock prohíbe acceder al dato. Hay shared lock por parte de las dos transacciones, pero la consigna pide leer, asíque se podría. Esa es mi humilde deducción.

Saludos.
14-07-2015 15:59
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
gaston monico Sin conexión
Militante
Sin estado :(
***

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 64
Agradecimientos dados: 0
Agradecimientos: 8 en 6 posts
Registro en: Dec 2010
Mensaje: #9
RE: Consulta final de gestion de datos
Buenas Noches chicos,

Bueno dejo mi aporte para ver si se aclaran dudas.

En repeatable Read, lo que deben saber es que no pueden ocurrir lecturas no repetibles. Ejemplo, una lectura no repetible sucede si T1 hace lectura y obtiene un registro, luego viene T2 que hace un update sobre el dato del registro, y nuevamente T1 hace otra lectura del registro, leerá lo que modificó T2. Por tanto, esto que acabo de ejemplificar no pasa en Repeatable Read.

Entonces, lo unico que bloquea Repeatable Read son las actualizaciones o modificaciones de los datos de registros, eso no lo permite. Por tanto, en este ejercicio, se realizan las operaciones tal cual están sin bloqueos ni esperas. En repeatable read, no se bloquea por lecturas (select), SALVO que si una T1 haya hecho un update y otro T2 quiera hacer un select sobre eso, entonces ahi si bloquea por lectura.

Por ultimo, Aqui tampoco se prohiben los inserts. Recuerden que en este nivel hay lecturas fantasmas, por tanto, si se bloquearan los agregados de filas con inserts o desagregados de filas con delete, las lecturas fantasmas no existirian en este nivel , lo que es falso. Si hay lecturas fantasmas, por lo tanto, se puede hacer inserts cuando se desee, siempre y cuando no haya un update antes sin commitearse.


Sugiero que se basen en las anomalías que pueden ocurrir en cada uno de los niveles, así van a entender mejor que ocurre en este tipo de planteos.

Comparto en un 100% con el planteo de "Chocolito", que explico un poco lo que pasa en este ejercicio.


Espero que se haya entendido algo,

Saludos, y aguardo opiniones =)
21-07-2015 21:35
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
roman1981 Sin conexión
Profesor del Modulo A
Sin estado :(
*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 260
Agradecimientos dados: 0
Agradecimientos: 15 en 8 posts
Registro en: Nov 2010
Mensaje: #10
RE: Consulta final de gestion de datos
ok gracias...ya que esta te consulto: un arbol binario de busqueda siempre es mas rapido que una lista para ordenar un conjunto de datos ..... es V o F para vos ?
(Este mensaje fue modificado por última vez en: 22-07-2015 08:38 por roman1981.)
21-07-2015 22:10
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
gaston monico Sin conexión
Militante
Sin estado :(
***

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 64
Agradecimientos dados: 0
Agradecimientos: 8 en 6 posts
Registro en: Dec 2010
Mensaje: #11
RE: Consulta final de gestion de datos
Buenos días Roman,

No estoy seguro, pero me parece que es falsa, no siempre ocurre eso depende del orden en que vienen los elementos a ordenar. Ya sea un vector (Quicksort) o una lista, trabajan de la misma manera. Y pierden performance cuando vienen ordenados. Sin embargo, tambien ABB pierde perfomance. Asi que no estoy seguro

Si llego a encontrar alguna justificación, la comparto por este medio.

Saludos, atte.,
23-07-2015 12:28
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.