SlideShare una empresa de Scribd logo
1 de 5
Candados en las Bases de datos o Sistemas distribuidos.
Una de las principales técnicas para controlar la ejecución concurrente de las
transacciones se basa en el concepto de bloquear elementos de información. Un
candado es una variable asociada a un elemento de información de la base de
datos y describe el estado de ese elemento respecto a las posibles operaciones
que se pueden aplicar a él. En general, hay un candado por cada elemento de
información en la base de datos. Usamos los candados como una forma de
sincronizar el acceso a los elementos de la base de datos por parte de
transacciones concurrentes.
Podemos usar varios tipos de candados en el control de la concurrencia.
Candados primarios: Un candado binario puede tener dos estados o valores:
bloqueado y desbloqueado (1,0). A cada elemento X de la base de datos se
asocia un candado distinto. Si el valor del candado sobre X es 1, ninguna
operación de la base de datos que solicite el elemento podrá tener acceso a él. Si
el valor del candado sobre X es 0, se podrá tener acceso al elemento cuando se
solicite. No referiremos al valor del candado asociado al elemento X como
CANDADO(X).
Cuando se usa el bloqueo binario se debe incluir en las transacciones dos
operaciones, bloquear_elemento y desbloquear_elemento. Una transacción
solicita acceso a un elemento X emitiendo una operación bloquear_elemento(X).
SI CANDADO(X)=1, la transacción tiene que esperar; si no, la transacción asigna
1 a CANDADO(X) (bloquea el elemento) y tiene que esperar; si no, la transacción
obtiene el acceso. Cuando la transacción termina de usar el elemento, emite una
operación desbloquear_elemento(X), que asigna 0 a CANDADO(X) (desbloquea
elemento) para que otras transacciones puedan tener acceso a X. Así pues, un
candado binario impone una exclusión mutua sobre el elemento de información.
El SGBD cuenta con un subsistema gestor de bloqueo para mantenerse al tanto
del acceso a los candados y controlarlos.
Cuando se utiliza el esquema de bloqueo binario, toda transacción debe obedecer
las siguientes reglas:
Una transacción T debe emitir una operación bloquear_elemento(X) antes de que
se realice cualquier operación leer_elemento(X) o escribir_elemento(X) en T.
Una transacción T debe emitir la operación desbloquear_elemento(X) después de
haber completado todas las operaciones leer_elemento(X) y escribir_elemento(X)
en T.
Una transacción T no emitirá una operación bloquear_elemento(X) si ya posee el
bloqueo del elemento X.
Una transacción T no emitirá una operación desbloquear_elemento(X) a menos
que ya posea el bloqueo del elemento X.
Candados compartidos y exclusivos. Permite que varias transacciones tengan
acceso al mismo elemento X si lo hace exclusivamente para leerlo. Sin embargo,
si una transacción va a escribir un elemento X deberá poseer acceso exclusivo a
él. A este tipo de candado se le llama candado de modo múltiple. en este
esquema hay tres operaciones de bloqueo: bloquear_lectura(X),
bloquear_escritura(X) y desbloquear(X). Ahora un candado asociado a un
elemento X, CANDADO(X), tiene tres posibles estados: bloqueado para leer,
bloqueado para escribir o desbloqueado.
Cuando usamos el esquema de bloqueo múltiple, el sistema debe hacer cumplir
las siguientes reglas:
Una transacción T debe emitir la operación bloquear_lectura(X) o
bloquear_escritura(X) antes de que realice cualquier operación leer_elemento(X)
de T.
Una transacción T debe emitir la operación bloquear_escritura(X) antes de que
realice cualquier operación escribir_elemento(X) de T.
Una transacción T debe emitir la operación desbloquear_elemento(X) una vez que
se hayan completado todas las operaciones leer_elemento(X) y
escribir_elemento(X) de T.
Una transacción T no emitirá una operación bloquear_lectura(X) si ya posee un
candado de lectura (compartido) o de escritura (exclusivo) para el elemento X.
Esta regla debe permitir excepciones.
Una transacción T no emitirá una operación bloquear _escritura(X) si ya posee un
candado de lectura (compartido) o de escritura (exclusivo) para el elemento X.
Esta regla debe de permitir excepciones.
Una transacción T no emitirá una operación desbloquear(X) a menos que ya
posea un candado de lectura (compartido) o de escritura (exclusivo) para el
elemento X.
En ocasiones es deseable permitir excepciones a las condiciones 4 y 5 de las lista
anterior. Por ejemplo, es posible que una transacción T emita un
bloquear_lectura(X) y más adelante promueva el bloqueo emitiendo una operación
bloquear_escritura(X). Si T es la única transacción con bloqueo de lectura para X
en el momento en que se emita la operación bloquear_escritura(X), es posible
promover el bloqueo. Una transacción T también puede emitir un
bloquear_escritura(X) y después degradar el candado emitiendo una operación
bloquear_lectura(X). Si permitimos la promoción y la degradación de candados,
deberemos incluir identificadores de transacciones en la estructura de registro de
cada candado para almacenar la información de cual transacción posee candados
para el elemento, y deberemos hacer modificaciones apropiadas a las
descripciones de la operaciones bloquear_lectura(X) y bloquear_escritura(X).
El empleo de candados binarios o de modo múltiple en las transacciones, según
descripción anterior no garantiza la seriabilidad de los planes en los que participan
las transacciones. Para garantizar la seriabilidad debemos seguir un protocolo
adicional sobre la ubicación de las operaciones de bloqueo y desbloqueo dentro
de las transacciones. El protocolo mejor conocido es el bloqueo de dos fases.
Bloqueo de dos fases (Básico)
Se dice que una transacción sigue el protocolo de bloqueo de dos fases si todas
las operaciones de bloqueo (bloquear_escritura, bloquear_lectura) preceden a la
primera operación de desbloqueo en la transacción. una transacción así puede
dividirse en dos fases: una fase de expansión (o de crecimiento), durante la cual
se pueden adquirir nuevos candados sobre elementos pero no se puede liberar
ninguno; y una fase de contracción, durante la cual se pueden liberar los candados
existentes, pero no es pueden adquirir nuevos candados. Si se permite promover
candados, esta definición no cambia. Pero, si también se permite la degradación
de candados, la definición debe alterarse ligeramente, porque todas las
degradaciones deben efectuarse en la fase de contracción. Así, una operación
bloquear_lectura(X) que degrada un candado de escritura que ya se tenía sobre X
solo puede aparecer en la fase de contracción de la transacción.
El bloqueo de dos fases puede limitar el grado de concurrencia que pueda haber
en un plan. La razón es que una transacción T tal vez no pueda liberar un
elemento X cuando termine de usarlo si T debe bloquear un elemento adicional Y
más adelante; o bien, T deberá bloquear el elemento adicional Y antes de
necesitarlo para poder liberar X. Así pues, X debe permanecer bloqueado por T
hasta que está haya bloqueado todos los elementos que va a necesitar; sólo
entonces podrá T liberar X. Mientras tanto, otra transacción que desee tener
acceso a X podría verse obligada a esperar, aunque T ya haya terminado de
usarlo; o bien, si Y queda bloqueado antes de que se le necesite realmente, otra
transacción que desee tener acceso a él se verá obligada a esperar aunque T
todavía no esté usando Y. Éste es el precio de garantizar la seriabilidad de todos
los planes sin tener que examinar los planes mismos.
Bloqueo de dos fases (conservador o estático)
Requiere que una transacción bloquee todos los elementos a los que tendrá
acceso antes de comenzar a ejecutarse, pre declarando su conjunto de lectura y
su conjunto de escritura. Si no es posible bloquear cualquiera de los elementos
pre declarados necesarios, la transacción no bloqueará ningún elemento; en vez
de ello, esperará hasta que todos los elementos estén disponibles para
bloquearlos. El B2F conservador es un protocolo libre de bloqueo mortal.
Bloque de dos fases (estricto)
En la práctica es la variación más utilizada. En él, una transacción T no libera
ninguno de sus candados antes de confirmares o de abortar; por tanto, ninguna
otra transacción puede leer o escribir un elemento escrito por T a menos que T ya
se haya confirmado, dando lugar a un plan estricto en cuanto a recuperabilidad. El
B2F estricto no está libre de bloqueo mortal a menos que se combine con el B2F
conservador.
Aunque el bloqueo de dos fases garantiza la seriabilidad, el empleo de candados
puede provocar dos problemas adicionales: bloqueo mortal y espera indefinida.
Bloqueo mortal
Hay bloqueo mortal cuando dos transacciones están esperando que la otra libere
su candado sobre un elemento. Mientras esto sucede, ninguna de las dos puede
proceder a desbloquear el elemento que la otra está esperando, y las demás
transacciones no pueden tener acceso ni al elemento X ni a Y. También puede
haber un bloqueo mortal en el que intervienen más de dos transacciones.
Protocolos de prevención de bloqueo mortal
Marca de tiempo en transacción MT(T): es un identificador único asignado a cada
transacción. Las marcas de tiempo ordenan con base en el orden en que se
inician las transacciones; así pues, si la transacción T1 se inicia antes que la
transacción T2, entonces MT(T1) < MT(T2).
Algoritmo de no esperar
Si una transacción no puede obtener un candado, se aborta de inmediato y se
reinicia después de cierto lapso sin comprobar si realmente ocurrirá un bloque
mortal o no. En vista de que este esquema puede hacer que algunas
transacciones se aborten y reinicien innecesariamente, se propuso el enfoque de
espera cautelosa para intentar reducir el número de abortos/reinicios innecesarios.
Tiempos predefinidos
Si una transacción espera durante un lapso mayor que un tiempo predefinido por
el sistema, éste supondrá que latransacción está en un bloqueo mortal y la
abortará, sin importar si existe o no realmente una situación de bloqueo mortal.
Un segundo enfoque para resolver el problema es la detección de bloqueo mortal,
en al que se verifica periódicamente si el sistema está en un estado de bloqueo
mortal. Esta solución es atractiva si sabemos que va a haber poca interferencia
entre las transacciones; es decir, si las diferentes transacciones casi nunca
tendrán acceso a los mismos elementos al mismo tiempo. Esto puede suceder si
las transacciones son cortas y cada una bloquea apenas unos cuantos elementos,
o si la carga de transacciones es ligera. Por otro lado, si las transacciones son
largas y cada una utiliza muchos elementos, o si la carga de transacciones es
bastante pesada, es más conveniente usar un esquema de prevención de bloqueo
mortal. Una forma sencilla de detectar un estado de bloqueo mortal es construir un
grafo de espera.
La espera indefinida
Una transacción se encuentra en un estado de espera indefinida si no puede
continuar durante un periodo indeterminado mientras otras transacciones del
sistema continúan con normalidad. Esto puede ocurrir si el esquema de espera de
elementos bloqueados es injusto y confiere a algunas transacciones mayor
prioridad que a otras. La solución estándar para la espera indefinida es contar con
un esquema de espera justo. Un esquema de este tipo utiliza una cola (FIFO)
primero que llega, primero que se atiende.
Algoritmos de control de concurrencia Basados en bloqueos.
En los algoritmos basados en candados las transacciones indican sus intenciones
solicitando candados al despachador (llamado el administrador de candados), los
candados son de lectura también llamados compartidos o de escrituras también
llamados exclusivos.
En sistemas basados en candados, el despachador es un administrador de
candados (LM). El administrador de transacciones le pasa al administrador de
candados la operación sobre la base de datos (lectura o escritura) e información
asociada, como por ejemplo el elemento de datos que es accesado y el
identificador de la transacción que está enviando la operación a la base de datos.
El administrador de candados verifica si el elemento de datos que se quiere
accesar ya ha sido bloqueado por un candado. Si candado solicitado es
incompatible con el candado con que el dato está bloqueado, entonces, la
transacción solicitante es retrasada. De otra forma, el candado se define sobre el
dato en el modo deseado y la operación a la base de datos es transferida al
procesador de datos. El administrador de transacciones es informado luego sobre
el resultado de la operación. La terminación de una transacción libera todos los
candados y se puede iniciar otra transacción que estaba esperando el acceso al
mismo dato.

Más contenido relacionado

La actualidad más candente

Sincronización entre procesos
Sincronización entre procesosSincronización entre procesos
Sincronización entre procesosIchinose 11
 
Administración de transacciones, problemas, candados e interbloqueos
Administración de transacciones, problemas, candados e interbloqueosAdministración de transacciones, problemas, candados e interbloqueos
Administración de transacciones, problemas, candados e interbloqueosjocuva101
 
Sistemas paralelos vs distribuidos
Sistemas paralelos vs distribuidosSistemas paralelos vs distribuidos
Sistemas paralelos vs distribuidosJesús Navarro
 
Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1jmpov441
 
Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetosAnálisis y diseño orientado a objetos
Análisis y diseño orientado a objetosChristian Leon
 
Modelo componentes
Modelo componentesModelo componentes
Modelo componentesmartin
 
Recopilacion De Informacion De Ing.Sofware
Recopilacion De Informacion De Ing.SofwareRecopilacion De Informacion De Ing.Sofware
Recopilacion De Informacion De Ing.Sofwarecarolina
 
Administración de Transacciones - del tema 1 al 4
Administración de Transacciones - del tema 1 al 4Administración de Transacciones - del tema 1 al 4
Administración de Transacciones - del tema 1 al 4Mayito Pdg
 
UML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de ClaseUML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de ClaseGuillermo Díaz
 
Cuadro comparativo de SMBD
Cuadro comparativo de SMBD Cuadro comparativo de SMBD
Cuadro comparativo de SMBD Jazmin Glez.
 
SO Unidad 2: Mecanismos de comunicación y sincronización de procesos
SO Unidad 2: Mecanismos de comunicación y sincronización de procesosSO Unidad 2: Mecanismos de comunicación y sincronización de procesos
SO Unidad 2: Mecanismos de comunicación y sincronización de procesosFranklin Parrales Bravo
 

La actualidad más candente (20)

Transaccion
TransaccionTransaccion
Transaccion
 
Sincronización entre procesos
Sincronización entre procesosSincronización entre procesos
Sincronización entre procesos
 
Taller de Base de Datos - Unidad 6 SQL procedural
Taller de Base de Datos - Unidad 6 SQL proceduralTaller de Base de Datos - Unidad 6 SQL procedural
Taller de Base de Datos - Unidad 6 SQL procedural
 
Administración de transacciones, problemas, candados e interbloqueos
Administración de transacciones, problemas, candados e interbloqueosAdministración de transacciones, problemas, candados e interbloqueos
Administración de transacciones, problemas, candados e interbloqueos
 
Sistemas paralelos vs distribuidos
Sistemas paralelos vs distribuidosSistemas paralelos vs distribuidos
Sistemas paralelos vs distribuidos
 
Transacciones
TransaccionesTransacciones
Transacciones
 
Modelo relacional
Modelo relacionalModelo relacional
Modelo relacional
 
Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1
 
Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetosAnálisis y diseño orientado a objetos
Análisis y diseño orientado a objetos
 
Gestión de archivos
Gestión de archivosGestión de archivos
Gestión de archivos
 
Diagrama de Casos de uso
Diagrama de Casos de usoDiagrama de Casos de uso
Diagrama de Casos de uso
 
Modelo componentes
Modelo componentesModelo componentes
Modelo componentes
 
Bloqueos _
Bloqueos _Bloqueos _
Bloqueos _
 
Recopilacion De Informacion De Ing.Sofware
Recopilacion De Informacion De Ing.SofwareRecopilacion De Informacion De Ing.Sofware
Recopilacion De Informacion De Ing.Sofware
 
Algebra relacional
Algebra relacionalAlgebra relacional
Algebra relacional
 
Administración de Transacciones - del tema 1 al 4
Administración de Transacciones - del tema 1 al 4Administración de Transacciones - del tema 1 al 4
Administración de Transacciones - del tema 1 al 4
 
UML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de ClaseUML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de Clase
 
Cuadro comparativo de SMBD
Cuadro comparativo de SMBD Cuadro comparativo de SMBD
Cuadro comparativo de SMBD
 
SO Unidad 2: Mecanismos de comunicación y sincronización de procesos
SO Unidad 2: Mecanismos de comunicación y sincronización de procesosSO Unidad 2: Mecanismos de comunicación y sincronización de procesos
SO Unidad 2: Mecanismos de comunicación y sincronización de procesos
 
PROTOCOLO DE BLOQUEO EN 2 FASES
PROTOCOLO DE BLOQUEO EN 2 FASESPROTOCOLO DE BLOQUEO EN 2 FASES
PROTOCOLO DE BLOQUEO EN 2 FASES
 

Similar a Candados en bases de datos

Capítulo 18 (Técnicas de control de la concurrencia)
Capítulo 18 (Técnicas de control de la concurrencia)Capítulo 18 (Técnicas de control de la concurrencia)
Capítulo 18 (Técnicas de control de la concurrencia)Liz Ocampo
 
Gestion de transacciones
Gestion de transaccionesGestion de transacciones
Gestion de transaccionesPatricia Flores
 
Blockchain
BlockchainBlockchain
Blockchainjjmch
 
Presentacion grupo1 -_bloqueo_binario
Presentacion grupo1 -_bloqueo_binarioPresentacion grupo1 -_bloqueo_binario
Presentacion grupo1 -_bloqueo_binarioKEVINROLANDOGONZALEZ
 
BD: Cuestiones de Repaso del Capitulo 20.
BD: Cuestiones de Repaso del Capitulo 20.BD: Cuestiones de Repaso del Capitulo 20.
BD: Cuestiones de Repaso del Capitulo 20.Victor Samaniego
 
Cuestiones de Repaso Capitulo 20
Cuestiones de Repaso Capitulo 20Cuestiones de Repaso Capitulo 20
Cuestiones de Repaso Capitulo 20eeencalada
 
Transacciones en transact sql
Transacciones en transact sqlTransacciones en transact sql
Transacciones en transact sqlFreddy Poma Inga
 
Concurrencia bases datos 2
Concurrencia bases datos 2Concurrencia bases datos 2
Concurrencia bases datos 2Velmuz Buzz
 
Gestion de transacciones "Investigación"
Gestion de transacciones "Investigación"Gestion de transacciones "Investigación"
Gestion de transacciones "Investigación"UNIVERSIDAD VERACRUZANA
 

Similar a Candados en bases de datos (20)

Abd clase 9 y 10
Abd clase 9 y 10Abd clase 9 y 10
Abd clase 9 y 10
 
Capítulo 18 (Técnicas de control de la concurrencia)
Capítulo 18 (Técnicas de control de la concurrencia)Capítulo 18 (Técnicas de control de la concurrencia)
Capítulo 18 (Técnicas de control de la concurrencia)
 
Gestion de transacciones
Gestion de transaccionesGestion de transacciones
Gestion de transacciones
 
Blockchain
BlockchainBlockchain
Blockchain
 
Transacciones.pptx julio
Transacciones.pptx julioTransacciones.pptx julio
Transacciones.pptx julio
 
Transacciones.pptx julio
Transacciones.pptx julioTransacciones.pptx julio
Transacciones.pptx julio
 
Presentacion grupo1 -_bloqueo_binario
Presentacion grupo1 -_bloqueo_binarioPresentacion grupo1 -_bloqueo_binario
Presentacion grupo1 -_bloqueo_binario
 
BD: Cuestiones de Repaso del Capitulo 20.
BD: Cuestiones de Repaso del Capitulo 20.BD: Cuestiones de Repaso del Capitulo 20.
BD: Cuestiones de Repaso del Capitulo 20.
 
Transacciones
TransaccionesTransacciones
Transacciones
 
Tarea
TareaTarea
Tarea
 
Gestion de transacciones
Gestion de transaccionesGestion de transacciones
Gestion de transacciones
 
Cuestiones de Repaso Capitulo 20
Cuestiones de Repaso Capitulo 20Cuestiones de Repaso Capitulo 20
Cuestiones de Repaso Capitulo 20
 
Sistemas Operativos
Sistemas OperativosSistemas Operativos
Sistemas Operativos
 
Chap 15epin
Chap 15epinChap 15epin
Chap 15epin
 
Transacciones en transact sql
Transacciones en transact sqlTransacciones en transact sql
Transacciones en transact sql
 
Concurrencia bases datos 2
Concurrencia bases datos 2Concurrencia bases datos 2
Concurrencia bases datos 2
 
Gestion de transacciones "Investigación"
Gestion de transacciones "Investigación"Gestion de transacciones "Investigación"
Gestion de transacciones "Investigación"
 
Abd clase 5 y 6
Abd clase 5 y 6Abd clase 5 y 6
Abd clase 5 y 6
 
2.4 Cuestionario de comunicacion entre procesos
2.4 Cuestionario de comunicacion entre procesos2.4 Cuestionario de comunicacion entre procesos
2.4 Cuestionario de comunicacion entre procesos
 
UNIDAD II ADMINISTRADOR DE PROCESADOR
UNIDAD II ADMINISTRADOR DE PROCESADORUNIDAD II ADMINISTRADOR DE PROCESADOR
UNIDAD II ADMINISTRADOR DE PROCESADOR
 

Candados en bases de datos

  • 1. Candados en las Bases de datos o Sistemas distribuidos. Una de las principales técnicas para controlar la ejecución concurrente de las transacciones se basa en el concepto de bloquear elementos de información. Un candado es una variable asociada a un elemento de información de la base de datos y describe el estado de ese elemento respecto a las posibles operaciones que se pueden aplicar a él. En general, hay un candado por cada elemento de información en la base de datos. Usamos los candados como una forma de sincronizar el acceso a los elementos de la base de datos por parte de transacciones concurrentes. Podemos usar varios tipos de candados en el control de la concurrencia. Candados primarios: Un candado binario puede tener dos estados o valores: bloqueado y desbloqueado (1,0). A cada elemento X de la base de datos se asocia un candado distinto. Si el valor del candado sobre X es 1, ninguna operación de la base de datos que solicite el elemento podrá tener acceso a él. Si el valor del candado sobre X es 0, se podrá tener acceso al elemento cuando se solicite. No referiremos al valor del candado asociado al elemento X como CANDADO(X). Cuando se usa el bloqueo binario se debe incluir en las transacciones dos operaciones, bloquear_elemento y desbloquear_elemento. Una transacción solicita acceso a un elemento X emitiendo una operación bloquear_elemento(X). SI CANDADO(X)=1, la transacción tiene que esperar; si no, la transacción asigna 1 a CANDADO(X) (bloquea el elemento) y tiene que esperar; si no, la transacción obtiene el acceso. Cuando la transacción termina de usar el elemento, emite una operación desbloquear_elemento(X), que asigna 0 a CANDADO(X) (desbloquea elemento) para que otras transacciones puedan tener acceso a X. Así pues, un candado binario impone una exclusión mutua sobre el elemento de información. El SGBD cuenta con un subsistema gestor de bloqueo para mantenerse al tanto del acceso a los candados y controlarlos. Cuando se utiliza el esquema de bloqueo binario, toda transacción debe obedecer las siguientes reglas: Una transacción T debe emitir una operación bloquear_elemento(X) antes de que se realice cualquier operación leer_elemento(X) o escribir_elemento(X) en T. Una transacción T debe emitir la operación desbloquear_elemento(X) después de haber completado todas las operaciones leer_elemento(X) y escribir_elemento(X) en T. Una transacción T no emitirá una operación bloquear_elemento(X) si ya posee el bloqueo del elemento X. Una transacción T no emitirá una operación desbloquear_elemento(X) a menos que ya posea el bloqueo del elemento X.
  • 2. Candados compartidos y exclusivos. Permite que varias transacciones tengan acceso al mismo elemento X si lo hace exclusivamente para leerlo. Sin embargo, si una transacción va a escribir un elemento X deberá poseer acceso exclusivo a él. A este tipo de candado se le llama candado de modo múltiple. en este esquema hay tres operaciones de bloqueo: bloquear_lectura(X), bloquear_escritura(X) y desbloquear(X). Ahora un candado asociado a un elemento X, CANDADO(X), tiene tres posibles estados: bloqueado para leer, bloqueado para escribir o desbloqueado. Cuando usamos el esquema de bloqueo múltiple, el sistema debe hacer cumplir las siguientes reglas: Una transacción T debe emitir la operación bloquear_lectura(X) o bloquear_escritura(X) antes de que realice cualquier operación leer_elemento(X) de T. Una transacción T debe emitir la operación bloquear_escritura(X) antes de que realice cualquier operación escribir_elemento(X) de T. Una transacción T debe emitir la operación desbloquear_elemento(X) una vez que se hayan completado todas las operaciones leer_elemento(X) y escribir_elemento(X) de T. Una transacción T no emitirá una operación bloquear_lectura(X) si ya posee un candado de lectura (compartido) o de escritura (exclusivo) para el elemento X. Esta regla debe permitir excepciones. Una transacción T no emitirá una operación bloquear _escritura(X) si ya posee un candado de lectura (compartido) o de escritura (exclusivo) para el elemento X. Esta regla debe de permitir excepciones. Una transacción T no emitirá una operación desbloquear(X) a menos que ya posea un candado de lectura (compartido) o de escritura (exclusivo) para el elemento X. En ocasiones es deseable permitir excepciones a las condiciones 4 y 5 de las lista anterior. Por ejemplo, es posible que una transacción T emita un bloquear_lectura(X) y más adelante promueva el bloqueo emitiendo una operación bloquear_escritura(X). Si T es la única transacción con bloqueo de lectura para X en el momento en que se emita la operación bloquear_escritura(X), es posible promover el bloqueo. Una transacción T también puede emitir un bloquear_escritura(X) y después degradar el candado emitiendo una operación bloquear_lectura(X). Si permitimos la promoción y la degradación de candados, deberemos incluir identificadores de transacciones en la estructura de registro de cada candado para almacenar la información de cual transacción posee candados para el elemento, y deberemos hacer modificaciones apropiadas a las descripciones de la operaciones bloquear_lectura(X) y bloquear_escritura(X). El empleo de candados binarios o de modo múltiple en las transacciones, según descripción anterior no garantiza la seriabilidad de los planes en los que participan las transacciones. Para garantizar la seriabilidad debemos seguir un protocolo
  • 3. adicional sobre la ubicación de las operaciones de bloqueo y desbloqueo dentro de las transacciones. El protocolo mejor conocido es el bloqueo de dos fases. Bloqueo de dos fases (Básico) Se dice que una transacción sigue el protocolo de bloqueo de dos fases si todas las operaciones de bloqueo (bloquear_escritura, bloquear_lectura) preceden a la primera operación de desbloqueo en la transacción. una transacción así puede dividirse en dos fases: una fase de expansión (o de crecimiento), durante la cual se pueden adquirir nuevos candados sobre elementos pero no se puede liberar ninguno; y una fase de contracción, durante la cual se pueden liberar los candados existentes, pero no es pueden adquirir nuevos candados. Si se permite promover candados, esta definición no cambia. Pero, si también se permite la degradación de candados, la definición debe alterarse ligeramente, porque todas las degradaciones deben efectuarse en la fase de contracción. Así, una operación bloquear_lectura(X) que degrada un candado de escritura que ya se tenía sobre X solo puede aparecer en la fase de contracción de la transacción. El bloqueo de dos fases puede limitar el grado de concurrencia que pueda haber en un plan. La razón es que una transacción T tal vez no pueda liberar un elemento X cuando termine de usarlo si T debe bloquear un elemento adicional Y más adelante; o bien, T deberá bloquear el elemento adicional Y antes de necesitarlo para poder liberar X. Así pues, X debe permanecer bloqueado por T hasta que está haya bloqueado todos los elementos que va a necesitar; sólo entonces podrá T liberar X. Mientras tanto, otra transacción que desee tener acceso a X podría verse obligada a esperar, aunque T ya haya terminado de usarlo; o bien, si Y queda bloqueado antes de que se le necesite realmente, otra transacción que desee tener acceso a él se verá obligada a esperar aunque T todavía no esté usando Y. Éste es el precio de garantizar la seriabilidad de todos los planes sin tener que examinar los planes mismos. Bloqueo de dos fases (conservador o estático) Requiere que una transacción bloquee todos los elementos a los que tendrá acceso antes de comenzar a ejecutarse, pre declarando su conjunto de lectura y su conjunto de escritura. Si no es posible bloquear cualquiera de los elementos pre declarados necesarios, la transacción no bloqueará ningún elemento; en vez de ello, esperará hasta que todos los elementos estén disponibles para bloquearlos. El B2F conservador es un protocolo libre de bloqueo mortal. Bloque de dos fases (estricto) En la práctica es la variación más utilizada. En él, una transacción T no libera ninguno de sus candados antes de confirmares o de abortar; por tanto, ninguna otra transacción puede leer o escribir un elemento escrito por T a menos que T ya se haya confirmado, dando lugar a un plan estricto en cuanto a recuperabilidad. El
  • 4. B2F estricto no está libre de bloqueo mortal a menos que se combine con el B2F conservador. Aunque el bloqueo de dos fases garantiza la seriabilidad, el empleo de candados puede provocar dos problemas adicionales: bloqueo mortal y espera indefinida. Bloqueo mortal Hay bloqueo mortal cuando dos transacciones están esperando que la otra libere su candado sobre un elemento. Mientras esto sucede, ninguna de las dos puede proceder a desbloquear el elemento que la otra está esperando, y las demás transacciones no pueden tener acceso ni al elemento X ni a Y. También puede haber un bloqueo mortal en el que intervienen más de dos transacciones. Protocolos de prevención de bloqueo mortal Marca de tiempo en transacción MT(T): es un identificador único asignado a cada transacción. Las marcas de tiempo ordenan con base en el orden en que se inician las transacciones; así pues, si la transacción T1 se inicia antes que la transacción T2, entonces MT(T1) < MT(T2). Algoritmo de no esperar Si una transacción no puede obtener un candado, se aborta de inmediato y se reinicia después de cierto lapso sin comprobar si realmente ocurrirá un bloque mortal o no. En vista de que este esquema puede hacer que algunas transacciones se aborten y reinicien innecesariamente, se propuso el enfoque de espera cautelosa para intentar reducir el número de abortos/reinicios innecesarios. Tiempos predefinidos Si una transacción espera durante un lapso mayor que un tiempo predefinido por el sistema, éste supondrá que latransacción está en un bloqueo mortal y la abortará, sin importar si existe o no realmente una situación de bloqueo mortal. Un segundo enfoque para resolver el problema es la detección de bloqueo mortal, en al que se verifica periódicamente si el sistema está en un estado de bloqueo mortal. Esta solución es atractiva si sabemos que va a haber poca interferencia entre las transacciones; es decir, si las diferentes transacciones casi nunca tendrán acceso a los mismos elementos al mismo tiempo. Esto puede suceder si las transacciones son cortas y cada una bloquea apenas unos cuantos elementos, o si la carga de transacciones es ligera. Por otro lado, si las transacciones son largas y cada una utiliza muchos elementos, o si la carga de transacciones es bastante pesada, es más conveniente usar un esquema de prevención de bloqueo mortal. Una forma sencilla de detectar un estado de bloqueo mortal es construir un grafo de espera.
  • 5. La espera indefinida Una transacción se encuentra en un estado de espera indefinida si no puede continuar durante un periodo indeterminado mientras otras transacciones del sistema continúan con normalidad. Esto puede ocurrir si el esquema de espera de elementos bloqueados es injusto y confiere a algunas transacciones mayor prioridad que a otras. La solución estándar para la espera indefinida es contar con un esquema de espera justo. Un esquema de este tipo utiliza una cola (FIFO) primero que llega, primero que se atiende. Algoritmos de control de concurrencia Basados en bloqueos. En los algoritmos basados en candados las transacciones indican sus intenciones solicitando candados al despachador (llamado el administrador de candados), los candados son de lectura también llamados compartidos o de escrituras también llamados exclusivos. En sistemas basados en candados, el despachador es un administrador de candados (LM). El administrador de transacciones le pasa al administrador de candados la operación sobre la base de datos (lectura o escritura) e información asociada, como por ejemplo el elemento de datos que es accesado y el identificador de la transacción que está enviando la operación a la base de datos. El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si candado solicitado es incompatible con el candado con que el dato está bloqueado, entonces, la transacción solicitante es retrasada. De otra forma, el candado se define sobre el dato en el modo deseado y la operación a la base de datos es transferida al procesador de datos. El administrador de transacciones es informado luego sobre el resultado de la operación. La terminación de una transacción libera todos los candados y se puede iniciar otra transacción que estaba esperando el acceso al mismo dato.