PROBLEMAS CONCURRENCIA ACCESO

. Los SGBDs multiusuario necesitan un mecanismo de control de concurrencia para asegurar que ninguna transacción concurrente interfiera con las demás
. 3 problemas de concurrencia en transacciones correctas que pueden producir resultado incorrecto debido a “interferencias” de otras transacciones	. Modificación perdida à La modificación realizada por una transacción se pierde porque otra sobreescribe el resultado de la anterior
	. Dependencia no comprometida o lectura sucia	. Una transacción A lee (modifica) un reg. (fila) actualizado –pero no comprometido/confirmado/commit- por otra transacc. B . La lectura realizada por A es sucia porque ha leído un valor no confirmado
	. Análisis inconsistente o lectura fantasma	. El resultado de una transacción interfiere en el resultado de otra de duración mayor . P.e. una transacc. intermedia B modifica (y confirma) un valor leído antes por A,y que A vuelve a usar después de finalizar B . El proceso que esté haciendo A (p.e. acumular valores) puede ser inconsistente: no usa los valores más actualizados . La lectura realizada por A es como si no hubiese tenido lugar (si se volviese a efectuar una vez finalizado B, sería diferente) . Se llama lectura fantasma pq si la transacc A ejecuta dos lecturas idénticas, los resultados de la 2a son distintos de la 1ª . En la lectura sucia, el problema es la ausencia de confirmación, . En lect fantasma, SI hay confirmaciónàProblema:“duración” de la 2ª transacc (o volver a realizar op. afectada por cambios)
. SoluciónàBloqueos: cuando una transacción necesita garantizar el acceso a un objeto para que no cambie de manera no predecible, adquiere un bloqueo sobre ese objeto	. 2 tipos de bloqueo: si transacc. tiene bloqueo…	. Exclusivo (X): ninguna otra podrá acceder al mismo . Compartido (S): otra podrá acceder siempre que no implique modificación		Matriz de compatibilidades X X Sin bloqueo X N N S S N S S Sin bloqueo S S S
	. Las solicitudes de bloqueo por parte de las transacc son implícitas en condiciones normales (i.e., se activan en función de la orden SQL ejecutándose) . Los bloqueos se mantienen hasta el siguiente punto de sincronización: normalmente un commit o un rollback
	. Teniendo en cuenta estos bloqueos implícitos es posible resolver los problemas de concurrencia..aunque para la lectura fantasma o la modificación perdida puede provocar bloqueo mútuo	. El bloqueo implícito soluciona de manera definitiva la dependencia no comprometida o lectura sucia
		. En caso de aplicar bloqueo implícito al problema de la modificación perdida, se puede generar bloqueo mútuo
		. En el caso del análisis inconsistente o lectura fantasma, el bloqueo implícito puede generar bloqueo mútuo (aunque soluciona el problema del análisis inconsistente: ninguna transacción finaliza y no genera resultados erróneos))
. Bloqueo mútuo	. Ante un bloque mútuo, el sist lo debe detectar y romper: elige una transacc “paralizada” como víctima y la cancela, con lo que libera sus bloqueos
	. La transacción víctima una vez cancelada..	. En algunos casos se reinician de forma automática las transacc desde el ppio (suponiendo no se repetirá bloqueo mútuo) . En otros casos, se avisa a la aplicación de la transacc víctimaà Es responsabilidad del programador tratar el problema