PROPAGACION DE LA ACTUALIZACION

1. PROPAGACION DE LA ACTUALIZACION

2. PROPAGACION DE LA ACTUALIZACION • El problema básico que existe con la replicación de datos es que una actualización a cualquier objeto lógico debe ser propagada a todas las copias almacenadas de ese objeto. • Una dificultad inmediata es que un sitio que mantiene una copia del objeto podría no estar disponible en el momento de la actualización.

3. PROPAGACION DE LA ACTUALIZACION • Por lo tanto, la estrategia obvia para propagar inmediatamente las actualizaciones hacia todas las copias, es probablemente inaceptable. • Ya que implica que la actualización fallará, si alguna de esas copias no está disponible actualmente. • Un esquema común para atacar este problema es el llamado esquema de Copia Primaria.

4. PROPAGACION DE LA ACTUALIZACION El esquema de Copia Primaria, que funciona de la siguiente forma: • A una copia de cada objeto replicado se le designa como copia primaria. Todas las demás son copias secundarias. • Las copias primarias de diferentes objetos están en diferentes sitios (por lo tanto, éste es un esquema distribuido).

5. PROPAGACION DE LA ACTUALIZACION • Decimos que las operaciones de actualización quedaron lógicamente terminadas, tan pronto como se actualizó la copia primaria. Entonces, el sitio que mantiene esa copia es responsable de la propagación de la actualización hacia las copias secundarias, en algún tiempo subsecuente.

6. PROPAGACION DE LA ACTUALIZACION • Observe que representa una violación al objetivo de autonomía local. • Debido a que una transacción ahora puede fallar debido a que alguna copia primaria remota de un objeto podría no estar disponible; aunque sí esté disponible una copia local. • Replicación Síncrona (antes del COMMIT, se deben de actualizar las copias). • Replicación Asíncrona (la actualización se realiza en un momento posterior, después de efectuarse el COMMIT).

7. CONTROL DE LA RECUPERACION

8. CONTROL DE LA RECUPERACION • El control de la recuperación en los SD está basado típicamente en el ProtocolodeConfirmación de Dos Fases. • La confirmación de dos fases es necesaria en cualquier ambiente en el cual una transacción única puede interactuar con varios administradores de recursos autónomos. • Es particularmente importantes debido a que los administradores de los recursos en cuestión están operando en sitios distintos y por lo tanto son muy autónomos.

9. CONTROL DE LA RECUPERACION Veamos los siguientes puntos: • El objetivo de la “no dependencia de un sitio central” indica que la función coordinadora no debe ser asignada a un sitio distinguido o prioritario en la red. • Sino que en su lugar, debe ser realizada por sitios diferentes para transacciones diferentes. • Por lo general es manejada por el sitio en el cual se inicia la transacción en cuestión. • Cada sitio debe ser capaz de actuar como coordinador para algunas transacciones y como sitio participante para otras.

10. CONTROL DE LA RECUPERACION • El proceso de confirmación de dos fases requiere que el coordinador se comunique con cada uno de los sitios participantes. • Lo cual significa más mensajes y más sobrecarga. • Si un sitio Y actúa como participante en un proceso de confirmación de dos fases coordinado por el sitio X, entonces el sitio Y debe hacer lo que le indique el sitio X y esto es una pérdida de autonomía local.

11. CONTROL DE LA RECUPERACION Problemas asociados: • Fallo de sitios individuales. El DBMS debe seguir operando. Cuando un sitio se recupere debe ponerse al día. • Fallo en los enlaces de comunicación. • Confirmación distribuida. Puede haber problemas si algún sitio falla.

12. CONTROL DE LA CONCURRENCIA

13. CONTROL DE LA CONCURRENCIA • El control de la concurrencia está basado en el bloqueo, usado tanto en lo sistemas centralizados como distribuidos. • Sin embargo, en un SD las solicitudes para probar, poner y liberar bloqueos se convierten en mensajes y los mensajes significan una sobrecarga.

14. CONTROL DE LA CONCURRENCIA • Por ejemplo, considere una transacción T que necesita actualizar un objeto para el cual existen réplicas en n sitios remotos. • Si cada sitio es responsable de los bloqueos sobre los objetos que están almacenados en ese sitio, entonces una implementación directa requerirá al menos 5n mensajes: n solicitudes de bloqueos n otorgamientos de bloqueos n mensajes de actualización n notificaciones n solicitudes de desbloqueo

15. CONTROL DE LA CONCURRENCIA • Se puede resolver lo anterior si se “enciman” los mensajes. • Es decir, combinar mensajes de solicitud de bloqueo y los de actualización, así como los mensajes de garantía de bloqueo y los de notificación. • Pero aún así, el tiempo total para la actualización seguirá siendo varias veces mayor que como sucedería en un sistema centralizado.

16. CONTROL DE LA CONCURRENCIA • El enfoque actual para este problema es adoptar la estrategia de Copia Primaria. • Bajo esta estrategia, el conjunto de todas las copias de un objeto puede ser considerado como un solo objeto para efectos de bloqueo. • Y la cantidad total de mensajes se reducirá de 5n a 2n + 3: n actualizaciones y n notificaciones 1 solicitud de bloqueo 1 garantía de bloqueo, y 1 solicitud de desbloqueo

17. CONTROL DE LA CONCURRENCIA • Pero observe de nuevo que esta solución implica una (severa) pérdida de autonomía. • Ahora, una transacción puede fallar si no hay una copia primaria disponible, aun cuando la transacción sea de sólo lectura y tenga una copia local disponible. • Por lo tanto, un desagradable efecto lateral de la estrategia de copia primaria es la reducción del rendimiento y la disponibilidad para las recuperaciones y las actualizaciones.

18. CONTROL DE LA CONCURRENCIA • Otro problema con el bloqueo en un SD es que puede conducir a un bloqueo mortal global. • Donde un bloqueo mortal global es aquél que involucra dos o más sitios

19. SITIO X Mantiene el Bloqueo de Lx T1x T2x Espera que T1x libere a Lx Espera que T1y termine Espera que T2x termine Espera que T2y libere a Lx T1y T2y Mantiene el Bloqueo de Ly SITIO Y BLOQUEO MORTAL GLOBAL (DEAD LOCK)

20. CONTROL DE LA CONCURRENCIA • El problema con un bloqueo mortal global es que ningún sitio puede detectarlo usando solamente información interna de ese sitio. • En otras palabras, no hay ciclos en el grafo de espera local, pero aparecerá un ciclo si se combinan esos dos grafos locales para que formen un grafo global. • La detección del bloqueo mortal global incurre en más sobrecarga de comunicaciones, debido a que requiere que los grafos locales individuales estén reunidos de alguna forma.

21. SISTEMA CLIENTE/SERVIDOR

22. Petición Cliente Servidor Respuesta Arquitectura C/S SISTEMA C/S • Los sistemas cliente-servidor pueden ser considerados como un caso especial de los SD en general.

23. SISTEMA C/S Para ser más precisos, un sistema C/S es un SD en el cual: • Algunos sitios son: sitios clientes y algunos son servidores. • Todos los datos residen en los sitios servidores. • Todas las aplicaciones (de interfaz) son ejecutadas en los sitios clientes. • Se ven las “costuras”, es decir, no existe una independencia total de la ubicación.

24. SISTEMA C/S • Actualmente hay mucho interés comercial en los sistemas C/S y comparativamente poco en los SD verdaderos de propósito general. • El término C/S se refería principalmente a una arquitectura o división lógica de responsabilidades: • El cliente es la aplicación (a quien se conoce como interfaz o parte frontal, Front End). • El servidor es el DBMS (conocido también como servicios de fondo o parte dorsal, Back End).

25. SISTEMA C/S Recordemos que son posibles muchas variaciones del tema básico: • Varios clientes pueden compartir el mismo servidor (caso normal). • Un solo cliente puede acceder a varios servidores. Donde esta posibilidad se divide en dos casos siguientes:

26. SISTEMA C/S • El cliente está limitado a acceder a un solo servidor a la vez. • No es posible combinar, dentro de una sola solicitud, datos de dos o más servidores diferentes. • Además, el usuario debe saber cuál servidor almacena cuáles partes de datos. • El cliente puede acceder a muchos servidores simultáneamente. • Es decir, una sola solicitud de BD puede combinar datos de varios servidores. • Lo que significa que los servidores ven al cliente como si fueran en realidad, sólo un servidor. • Y el usuario no tiene que saber qué servidor almacena qué partes de datos.

27. SISTEMA C/S Estándares • SQL/92 • Estándar ISO de RDA (Remote Data Access), Acceso a Datos Remotos. RDA pretende definir formatos y protocolos para las comunicaciones C/S basados en SQL. • DRDA (Arquitectura de BD Relacionales Distribuidas) de IBM. Con objetivos similares que al RDA, pero difiere del estándar de SQL y se apega más a estándares de IBM.

28. SISTEMA C/S Programación de Aplicaciones C/S • La cantidad de mensajes entre c/s puede ser reducida si el sistema proporciona algún tipo de mecanismo de procedimiento almacenado. • Un procedimiento almacenado es básicamente un programa precompilado que está almacenado en el sitio servidor. • Y se llama desde el cliente mediante un RPC.

29. MIDDLEWARE

30. MIDDLEWARE PARA ACCESO A DATOS • Los productos del tipo “pasarela” han aparecido regularmente en los últimos años con cada vez más funcionalidad sofisticada. • De hecho todo el negocio de lo que ha venido siendo llamado middleware (también conocido como mediadores) es ahora una industria importante por derecho propio.

31. MIDDLEWARE PARA ACCESO A DATOS • Tienen sus inicios a partir de los Sistemas Distribuidos, usualmente heterogéneo, con una autonomía local cercana a la total. • Ya que en un sistema de éstos, las transacciones locales son administradas por el DBMS local. • Pero las transacciones globales son un asunto diferente, ya que necesita conectarse a los sitios de los cuales necesita información. • Y ahí es donde entran los middleware, el tratar de conectarse a cualquier manejador de manera transparente.

32. Sitio A Sitio B DBMS X DBMS Y MIDDLEWARE MIDDLEWARE Base de Datos Base de Datos Cliente MIDDLEWARE