UTNianos

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.

Gente...revivo el post para ver si algun alma caritativa me da una mano.

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

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.

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.

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 ?

Gente,,,si alguno me da una mano con este ejercicio??

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.

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

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 ?

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.,