el libro mencionado, no sirve, en ninguna parte explica acerca de como bloquear los registros.- si alguien tiene alguna idea, por favor comentela yo trabajo consql server y c++ builder
Registros de transacciones y bloqueos¿Cómo logran los sistemas de gestión de bases de datos que dos transacciones concurrentes no se estorben entre sí? La mayor parte de los sistemas, cuya arquitectura está basada en el arquetípico System R, utilizan técnicas basadas en bloqueos. Más adelante, al estudiar cómo se actualizan registros con C++ Builder, descubriremos que Paradox y dBase utilizan también bloqueos para garantizar el acceso exclusivo a registros, implementando un control de concurrencia pesimista . Sin embargo, aunque también se trata de “bloqueos”, el significado de los mismos es bastante diferente al que tienen en los sistemas SQL. Ahora veremos solamente cómo se adapta este mecanismo de sincronización a la implementación de transacciones.En primer lugar, ¿cómo evitar las “lecturas sucias”? Existen dos técnicas básicas. Lamás sencilla consiste en “marcar” el registro que modifica una transacción como“sucio”, hasta que la transacción confirme o anule sus grabaciones. A esta marca es lo que se le llama “bloqueo”. Si otra transacción intenta leer el valor del registro, se le hace esperar hasta que desaparezca la marca sobre el registro. Por supuesto, esta política se basa en un comportamiento “decente” por parte de las transacciones que modifican registros: no deben dejarse cambios sin confirmar o anular por períodos de tiempo prolongados.Ahora bien, ¿cómo es que la transacción que realiza el cambio restaura el valor original del registro si se decide su anulación? Lo más frecuente, en los sistemas inspirados por System R, es encontrar implementaciones basadas en registros de transacciones (transaction logs). Estos registros de transacciones son ficheros en los cuales se graban secuencialmente las operaciones necesarias para deshacer las transacciones no terminadas.Algunos guardan en el log el valor original; otros, por el contrario, guardan elnuevo valor no confirmado, y lo transfieren a la base de datos solamente al confirmarse la transacción. En la teoría de bases de datos, hablaríamos de undo y redo logs (registros para deshacer o rehacer). Cada técnica tiene sus ventajas y desventajas: por ejemplo, si se utiliza un registro de rehacer y alguien corta la corriente, la base de datos no queda afectada, y al volver a encender el sistema podemos seguir trabajando sobre un estado consistente. Sin embargo, la aplicación de los cambios durante la confirmación es sumamente peligrosa, y el implementador debe tomar precauciones extraordinarias.Esto nos da una idea para otra política de acceso: si una aplicación, al intentar leer un registro, encuentra que ha sido modificado, puede ir a buscar el valor original. Si utilizamos un redo log, el valor es el que se encuentra dentro del propio registro. En caso contrario, hay que buscarlo en el registro de transacciones. Por supuesto, esta técnica es superior a la anterior, pues ofrece mejores tiempos de acceso incluso en caso de modificaciones frecuentes.Paradox y dBase implementan un undo log, pero cuando una aplicación lee un registro modificado por otra transacción, no se toma la molestia de buscar el valororiginal en el log file. Por este motivo es que aparecen lecturas sucias.Todos los bloqueos impuestos por una transacción, por supuesto, son liberados alterminar ésta, ya sea confirmando o anulando.
Autor
Tema: Bloquear Registros (Leído 3021 veces)
