Sistemas de Operación II - ldc.usb.vefigueira/cursos/SOPII/Material/Transacciones.pdf · romper reglas integridad de la BD. ... Ejecución concurrente obtiene mismo efecto que ejecución

Sistemas de Operación II

Transacciones distribuidas

Prof. Carlos Figueira

Basado en material deYudith Cardinale (USB)

Andrew Tanembaum y Marteen van Steen

Carlos Figueira/USB 2

Contenido

● Transacciones: Introducción y definiciones● Algoritmos para completar transacciones ● Control de concurrencia● Tratamientos de interbloqueos


Transacciones:

IntroducciónDefiniciones


Transacción

● Unidad de cálculo consistente, confiable y atómica

● Aplica a datos recuperables● Puede estar formada por operaciones simples

o compuestas, pero deben ejecutarse de manera atómica

● Secuencia: ● abre transacción, operaciones, cierra transacción


Transacción

A B C

Serialización de operaciones conflictivas

Operaciones compuestas

Operaciones conflictivas

Retardo Ejecución


Requerimientos: Todo o nada

● Si una transacción termina exitosamente, los efectos de todas sus operaciones son registrados en espacio de datos

● Si falla, no altera espacio de datos, incluso ante fallas del servidor


Propiedades ACID

● Atomicidad: la operación se realiza completa o nada

● Consistencia: sólo se empieza aquello que se puede acabar.

● Aislamiento (isolation): una operación no puede afectar a otras.

● Durabilidad: una vez realizada, la operación persistirá, no se podrá deshacer aunque falle el sistema.


Atomicidad

● En la recuperación de caídas el sistema debe decidir qué hacer:● Terminar de ejecutar el resto de las acciones● Deshacer acciones que ya había realizado

● Se usan técnicas de almacenamiento estable● Se garantiza que permanecen incluso ante caídas

del servidor● Ejemplos: RAID, réplicas


Consistencia

● Una transacción toma el sistema en un estado consistente, y lo deja en un estado consistente

● Sólo se ejecutan operaciones que no van a romper reglas integridad de la BD.

● ¿Qué pasa con dos accesos simultáneos conflictivos? ● Ej: transferencias bancarias de cuenta A a cuentas

diferentes (B y C) cuyo monto total excede fondos en A


Aislamiento

● Dos transacciones sobre la misma información son independientes y no generan error

● Los efectos intermedios de una transacción son invisibles a las otras

● Ejecución concurrente obtiene mismo efecto que ejecución secuencial


Primitivas sobre transacciones

● inicio_transaccion → tid : inicia una transacción y devuelve un identificador de la transacción

● fin_transaccion → {Completar, Abortar}● Completar: la transacción termina exitosamente y sus efectos van a

almacenamiento permanente (commit: completar, consumar)● Abortar: no se reflejan los cambios. Pueden ser causados por la propia

naturaleza de la transacción, por conflictos con otras transacciones o por fallas.

● abortar_transaccion(tid): interrupción intencional.

● leer y escribir: típicamente una transacción se compone de una serie de lecturas y escrituras, y algunos cálculos.


Transacciones anidadas

● Ej: envío de correo electrónico a varios dest.● Transacción realiza completar y una + externa

abortar, se pierden propiedades de atomicidad y aislamiento por cumplir la durabilidad

● Generalmente, la durabilidad sólo se considera para la transacción más externa

● En algunos sistemas, la transacción superior puede decidir hacer completar aun cuando alguna sub-transacción aborta


Implementación de transacciones

● Espacio de trabajo privado● Se copian los datos en un espacio propio de cada

transacción● Al finalizar (exitosamente) la transacción, se

actualizan datos en almacenamiento permanente

● Lista de intención (write-ahead log)● Actualizaciones realizadas directamente en la BD● Se lleva registro de cambios realizados


Transacciones Distribuidas

● Involucran múltiples servidores

● Datos distribuidos entre varios servidores

● Transacción de un cliente puede incluir múltiples servidores

● Transacciones distribuidas pueden ser simples o anidadas

cliente

X

Z

Y

Cliente: inicio_transaccioncall X.xcall Y.ycall Z.z end_transaccion



Transacción distribuida anidada

T

Cliente

XT1

YT2

MT11

P

T22

NT12

T21



● Cuando termina transacción distribuida, la atomicidad exige que todos los servidores acuerden lo mismo (completar o abortar) o todos aborten (basta que uno aborte).

● Existen protocolos para llegar a compromisos (Two-phase-Commit y Three-Phase-Commit)

● Transacciones distribuidas deben ser globalmente serializables. Existen protocolos de control de concurrencia distribuida


Procesamiento de transacciones distribuidas

C C C

TransactionManager

scheduler

TPS

RecoveryManager

CacheManager

Data Manager

C C C

TransactionManager

scheduler

TPS

RecoveryManager

CacheManager

Data Manager

comunicación

TPS: Sistema de Procesamiento de Transacciones(TransactionProcessing System)



● Cliente inicia transacción sobre un TPS. El Manejador de Transacciones identifica y localiza objetos invocados.

● Invocaciones a objetos locales son pasados al Planificador local; invocaciones a objetos remotos son pasados a su TPS

● Cliente inicia transacción en un nodo => nodo coordinador

● Objeto reside en nodo único (no hay replicación de objeto). La invocación del objeto se hace en ese nodo



● Deben existir mecanismos para localizar un objeto, dado su identificador (único)

● Las instancias del TPS deben cooperar● Cuando un cliente comienza una transacción,

envía un inicio_transaccion a un servidor TPS.● El servidor TPS se convierte en coordinador● El resto de TPS que intervengan en la transacción

se convierten en trabajadores


Coordinador de transacción distribuida

● Se requieren otras primitivas● AgregaServidor (tid, id_servidor del

coordinador)● Mensaje enviado por coordinador a otro servidor

informando que participará en transacción tid.

● NuevoServidor (tid, id_servidor del trabajador)● Respuesta ante un AgregaServidor de un trabajador

al coordinador.● El coordinador lo registra en su lista de trabajadores


Algoritmos para completar (commit) transacciones


Algoritmos de completar (commit)

● Cuando el coordinador recibe un requerimiento completar de una transacción, debe asegurar:● Atomicidad: todos los nodos completan cambios o

ninguno lo hace; cualquier otra transacción percibe los cambios en todos los nodos o en ninguno

● Aislamiento: los efectos de la transacción no son visibles hasta que todos los nodos hayan tomado la decisión (irrevocable) de completar o abortar


Protocolo Completar en Dos Fases (C2F, Two-phase-commit)

● Durante progreso de transacción, no hay comunicación entre coordinador y trabajadores (excepto AgregarServidor y NuevoServidor)

● Requerimiento completar o abortar del cliente, llega al coordinador

● Si es abortar, el coordinador lo informa inmediatamente a todos los trabajadores

● Si es completar, se aplica protocolo C2F


Protocolo C2F

Máquina de estados finitos del coordinador (a) y de los trabajadores (b)


Protocolo C2F: acciones del coordinador (1/2)


Protocolo C2F: acciones del coordinador (2/2)


Protocolo C2F:

acciones del trabajador


C2F: esperas acotadas para tolerancia a fallas

● Se usan temporizadores para acotar espera en estados Espera, Completar y Abortar del coordinador. ● Expira (timeout) en el estado de Espera:

– aborta, escribe en bitácora, – envía mensaje abortar_global a todos

● Expira tiempo en estados Completar o Abortar:– envía mensaje completar_global o abortar_global, resp.,

a trabajadores que no han respondido– espera por confirmación


C2F: espera acotada en trabajador

● Estados Inicial o Listo● Expira en estado Inicial: decide abortar. Si el

mensaje solicita_voto (vote_request) llega después, trabajador envía un voto_abortar o lo ignora.

● Expira en estado Listo: se queda bloqueado esperando


Paradigmas de comunicación para el C2F

1 2 3 4 N

C Fase 1

Fase 2

C2F centralizado

C2F lineal

Solicita voto

voto C/A_global C/A

voto voto voto

C/A_gl C/A_gl C/A_gl C/A_gl


Paradigmas de comunicación: C2F distribuido

● El C/A_g (Commit/Abort_global) es decisión de cada participante de acuerdo a los votos recibidos

● Se elimina fase 2● Lineal y distribuidos requieren conocer ids de todos

los participantes

Solicita voto C/A_ voto C/A_g


Análisis de C2F

● El protocolo C2F puede ocasionar retrasos a los participantes en estado incierto (preparado para completar)● Cuando coordinador falla y no puede responder a

peticiones de dameDecisión. ● Lo mismo ocurre si es cooperativo y la pregunta va

a participantes en estado incierto

● Solución: Protocolo Completar en Tres fases (C3F)


Completar en Tres Fases (C3F Three-Phase-Commit)

● Los estados del coordinador y de cada participante satisfacen las siguientes dos condiciones:

1. No hay estado del cual sea posible hacer una transición directamente al estado completar o abortar

2. No hay estado en el cual no sea posible tomar una decisión final, y del cual pueda ser realizada una transición al estado completar


Completar en Tres Fases (C3F Three-Phase-Commit)

Máquina de estados finitos del coordinador (a) y de los trabajadores (b) en C3F


Control de Concurrencia


Control de Concurrencia

● Resolver operaciones conflictivas: cuando sus efectos combinados dependen del orden en el cual fueron ejecutadas

● Para dos transacciones, son conflictivas cualquier combinación que tenga escritura/lectura o escritura/escritura

● Si hay operaciones conflictivas es necesario serializarlas para asegurar la consistencia de los datos después de su ejecución


Control de concurrencia

● Las Operaciones conflictivas derivan en 2 problemas:

● Actualizaciones perdidas

Transacción T Transacción U

balance=b.getBalance() balance=b.getBalance()

b.setBalance(balance*1.1) b.setBalance(balance*1.1)

●Recuperaciones inconsistentes

Transacción V Transacción W

a.retirar(100) unasucursal.totalSucursal(a,b)

b.deposita(100))

● Solución: Equivalencia Secuencial =>

Control de concurrencia

Ejecución T Ubalance=200$ balance=200$ balance=220$balance=220$

Balance debió ser 200+20+22=242

Ejecución; a=200$ , b=200$ V Wa=200$-100$ lee a=100$ lee b=200$b=200$+100$ Total=300$Según la ejecución el total es 300$.

Debió ser 400$


Transacciones abortadas

● Cuando una transacción aborta, puede generar dos problemas:● Lecturas sucias● Escrituras prematuras


Lecturas sucias


a.getBalance() (100$)

a.depositar(10) (110$)

a.getBalance() (110$)

a.deposita(20) (130$)

completar

aborta

U tomó el valor 110$ que ahora no es válido


Recuperación de lecturas sucias

● Estrategia para recuperación: retrasar acción completar de U hasta que T finalice

● Esto puede generar Abortos en Cascada ● si T aborta, U debe abortar también


Escrituras prematuras

● Se pierden actualizaciones.● Ej: dos transacciones A y B sobre una cuenta.

Saldo inicial 100Bs. A pone balance en 105, B en 110, son secuencialmente equivalentes. B ejecuta después de A. – Si B aborta y después A, coloca 100 en balance

(correcto). – Si A aborta y después B, coloca 105 en balance

(incorrecto)

● Estrategia para recuperación● Retrasar escrituras hasta el momento de completar


Ejecución estricta

● Se retrasa lectura/escritura de un objeto hasta que todas las transacciones que escribieron el objeto han sido completadas o abortadas

● La ejecución estricta de las transacciones evita tanto lecturas sucias como escrituras prematuras (aislamiento)


Algoritmos de control de concurrencia

● Tres estrategias● Usando bloqueo (locking)● Optimista● Por marcas de tiempo (timestamp)


Control de concurrencia: Bloqueo

● Cuando se requiere leer/escribir objeto en una transacción, se bloquea objeto hasta que culmine transacción (completar)● Si otra transacción desea acceder el objeto, debe

esperar a que se desbloquee

● Los bloqueos (locks) son adquiridos/liberados por administrador de transacciones (transparente al programador)

● Administrador puede ser centralizado o local a cada máquina


Granularidad del Bloqueo

● Se refiere al tamaño del objeto que se está bloqueando:● A mayor granularidad, más pequeño (grano más

fino) es objeto

● Bloqueo puede ser a nivel de dato (mayor granularidad), página, archivo, BD (menor)

● Paralelismo/concurrencia, y complejidad de sistema, son directamente proporcionales a granularidad


Bloqueo: mejoras

● Bloqueos diferenciados para escritura y para lectura permiten más concurrencia

● Si varias transacciones requieren objeto para lectura y luego escritura, se otorga bloqueo de (sólo) lectura a todas, hasta que alguna requiera escribir; ● ésta solicita bloqueo de escritura (promoción de

bloqueo lectura a escritura), para lo cual debe esperar que todas las demás liberen bloqueo de lectura


Compatibilidad de bloqueos

● Determina cómo manejar los bloqueos solicitados sobre un objeto, sobre el cual existe un bloqueo activo

● Depende de los tipos de bloqueo solicitados y del bloqueo activo sobre el objeto

Bloqueo activo Bloqueo solicitadoNinguno Lectura OK – Escritura OK

Lectura Lectura OK – Escritura ESPERA

Escritura Lectura ESPERA – Escritura ESPERA


Problemas resueltos usando bloqueo

● Recuperaciones inconsistentes ● El bloqueo permite ordenar los accesos conflictivos

(en el ejemplo, evitando que W lea balance en b antes que V lo actualice)

● Pérdida de actualizaciones● si dos transacciones desean leer el mismo dato y

luego modificarlo, la solicitud de bloqueo de escritura (promoción lectura a escritura) de ambas forzará su ordenamiento


Equivalencia secuencial


bal=b.obtenBalance() (200)

b.ponBalance(bal*1.1) (220)

bal=b.obtentBalance() (220)

b.ponBalance(bal*1.1) (242)

a.extrae(bal/10) (80)

c.extrae(bal/10) (278)

● Transacciones deben planificarse para que efectos sean secuencialmente equivalentes, regulando solicitud/liberación de recursos


Bloqueo en dos fases

● Equivalencia Secuencial requiere que los accesos conflictivos a objetos se hagan en el mismo orden● Solución: impedir que se pidan objetos después de liberar

● Fase de Obtención: Transacción trata de obtener bloqueos necesitados. Si no es posible obtenerlos todos, entonces espera

● Fase de Liberación: Comienza cuando transacción libera algún bloqueo. A partir de ese momento, no podrá solicitar ningún otro; si lo hace, será abortada


Ejemplo bloqueo 2 fases


abreTransaccion

bal=b.obtenBalance() (bloquea B)

b.ponBalance(bal*1.1) abreTransaccion

a.extrae(bal/10) (bloquea A) bal=b.obtentBalance() (espera)

CierraTransaccion (desbloquea A,B)

Bloquea B

b.ponBalance(bal*1.1)

c.extrae(bal/10) (bloquea C)

cierraTransaccion (desbloq.B,C)


Desventaja de Bloqueo en dos fases

● Si una transacción en fase de liberación había desbloqueado algunos objetos que entonces son accedidos por otras antes que la primera haga completar, y ésta decide abortar, entonces TODAS deben abortar


Bloqueo en dos fases estricto

● La fase de liberación se realiza sólo cuando la transacción hace completar

● Ventaja: se evitan abortos en cascada (conjunto de transacciones relacionadas con los objetos bloqueados que deben abortar)

● Desventajas:● Degrada nivel de paralelismo● Permanece la posibilidad de interbloqueo● Representa alto costo de mantenimiento




Núm

ero de blo queos

Tiempo

Fase de crecimiento Fase de liberación Núm

ero de blo queos

Tiempo

Fase de crecimiento Fase de liberación

Se liberantodos losbloqueos

Bloqueo en dos fases estricto


Inconvenientes del uso de bloqueo

● Sobrecarga. Incluso en lectura, cuando no es necesario

● Posibilidad de interbloqueo● Pérdida de concurrencia

● Para impedir abortos en cascada, los bloqueos no pueden ser liberados hasta el final de la transacción


Control de concurrencia: Algoritmo Optimista

● Se basa en la premisa de que los conflictos son poco frecuentes, por lo que es mejor no hacer nada sino actuar cuando ocurran

● Modificaciones se hacen sobre espacios privados● Se lleva registro de los datos que han sido

modificados/accedidos● Al momento de completar, se verifica que los

espacios privados sean válidos; sino, aborta

● Asigna número de secuencia a transacciones


Fases de Algoritmo Optimista

● Tres fases: trabajo, validación y escritura● Trabajo

● Toda lectura se ejecuta inmediatamente sobre última versión completada del dato

● Las escrituras crean versiones tentativas● Se mantiene conjunto de lectura (datos leídos) y

conjunto de escritura (versiones tentativas de datos)


Fases de Algoritmo Optimista

● Validación● Ante solicitud de completar, se valida si transacción

realizó operaciones conflictivas con otras transacciones

● Escritura● Si transacción es validada, todos los cambios sobre

espacios privados se respaldan en espacio definitivo


Fase de Validación

● Ante cierraTransaccion de Tv, pasa a fase de validación; se asigna a cada transacción un número de secuencia

● Validación se basa en tres reglas (ver abajo, i<v)

Ti Tv Regla

Lectura Escritura 1. Ti no debe leer datos escritos por Tv

Escritura Lectura 2. Tv no debe leer datos escritos por Ti

Escritura Escritura 3. Ti no debe escribir datos escritos por Tv y viceversa


Validación hacia atrás

● Se cumple regla 1:● Puesto que Tv no escribe nada antes de llegar a

Validación

● Se cumple regla 3: ● Si realizamos fases Validación y Escritura dentro de

una sección crítica

● Sólo debemos validar regla 2 para cada Ti


Validación hacia atrás: regla 2

valido = true;for (Ti=nTinicio+1;Ti<=nTfinal,Ti++) {if (“conjunto_lectura” de Tv intersecta “conjunto_escritura” Ti) valido=false;}

nTinicio: número de transacción mayor asignado a transacción completada cuando Tv entra fase Trabajo

nTfinal: número de transacción mayor asignado al momento que Tv entra a su fase de Validación


Validación hacia atrás

● Sólo es necesario validar conjuntos de lecturas. Las transacciones que sólo hacen escritura no se validan

● Si Tv no es válida, se abortaT1

T2

T3

Tv

activa1

activa2

Transaccionesanteriores completadas

Transacción en validación

Trabajo Validación

Escritura

Sólo se validan T2 y T3 T1 terminó antes que Tv comenzara


Validación hacia adelante

● Se satisface regla 2 porque transacciones activas no escriben hasta que Tv no se ha completado

● Sólo se valida regla 1 para cada Ti:

valido= true;for (Tid=activa1;Tid<=activaN,Tid++) {if (“con_escritura” de Tv intersecta “conj_lectura” de Tid) valido=false;}

activaX: Transacciones que aún no entraron a fase de validaciónTransacciones que sólo hacen lecturas no requieren ser validadas


Validación hacia adelante

● Si Tv no es válida:● Aplazar validación (¿le irá mejor en el futuro?)● Abortar las activas y completa Tv● Abortar Tv (¿y si alguna de las futuras Tj es

abortada?)


Problemas con algoritmo optimista

● Posibilidad de inanición● no se puede prevenir que una transacción pueda

abortar indefinidas veces

● No funciona con carga alta● Produce sobrecarga porque hay que mantener

conjuntos de escrituras de transacciones que ya terminaron (validación hacia atrás)


Algoritmos por Marcas de Tiempo

● Las operaciones se validan al momento de ser ejecutadas

● Cuando comienza transacción, se le asigna fecha (timestamp)

● Usa versiones tentativas● Cada dato tiene asociado

– Fecha de escritura (Tcompletar_esc), fecha de lectura (Tlect) y conjunto de versiones tentativas con su fecha

● Una escritura aceptada genera una versión tentativa● Una lectura se dirige a versión con mayor fecha y

que sea menor que fecha de transacción


Reglas de validación

Tc Ti Regla

Escritura Lectura 1. Tc no debe escribir dato leído por Ti>Tc Requiere Tc>=max(Tlect del dato)

Escritura Escritura 2. Tc no debe escribir dato escrito por Ti>Tc (requiere Tc>=max(Tcompletar_esc del dato)

Lectura Escritura 3. Tc no debe leer dato escrito por Ti>Tc Requiere Tc>Tcompletar_esc


Algoritmos por Marcas de Tiempo

● Para saber cuando escritura es válida, se aplica el siguiente algoritmo (reglas de escritura 1 y 2)

Sea Tc una transacción que desea escribir sobre el objeto D.

if ((Tc >= Max (Tlect en D)) && (Tc > Tcompletar_esc en D))

Proceder con escritura sobre una versión tentativa nueva;else // escritura muy tarde

Abortar Tc;


Alg Marcas Tiempo: reglas escritura

T2

después

antes

T2 T3

T1

después

antes

T1 T2

T2

T3

T1

después

antes

T1 T3

T4

T4

T4

después

antes

T4

T3 Aborta

Versióntentativa

Versióncompletada

a) T3 escritura b) T3 escritura

d) T3 escriturac) T3 escritura

Tiempo


Alg. Marcas de Tiempo: validación de regla de lectura: Tc lee(D)

if (Tc > Tcompletar_esc en D) {Dselec con Max (Tescritura <=Tc en D);if (se completo (Dselec)) {

Procede lectura sobre Dselec;} else {

Espera hasta que Ti que hizo versión tentativa de Dselec haga completar o abortar;volver a comenzar;

} else {Abortar Tc;

}


Alg Marcas Tiempo: regla lectura

T2 T2 T4

T1 T2 T4 T3 Aborta

Seleccionado

lectura se ejecutainmediatamente

Seleccionado

lectura se ejecutainmediatamente

Seleccionado

lectura espera

a) T3 lectura

Versióntentativa

Tiempo

b) T3 lectura

d) T3 lecturac) T3 lectura


Interbloqueo


Condiciones para interbloqueo

1.Exclusión mutua.

Cada recurso está asignado a un único proceso o está disponible

2.Posesión y espera.

Procesos con recursos asignados pueden solicitar nuevos recursos.

3.No apropiación.

Recursos otorgados no pueden ser arrebatados a un proceso.

4.Espera circular.

Debe existir cadena circular de dos o más procesos, cada uno esperando recurso poseído porl siguiente miembro de la cadena.


Políticas frente a interbloqueos

1. Ignorar:el tratamiento del interbloqueo es responsabilidad del programador y/o de las acciones.

2. Detectar y recuperar:dejar que suceda y luego recuperarse.

3. Prevenir: Evitar que estructuralmente sea posible el interbloqueo, es decir, asegurar que al menos una de las cuatro condiciones no se cumpla.● Algoritmo del Banquero: Necesita conocer requerimientos de

recursos de procesos. ¡Muy complejo en sistemas distribuidos!


Tipos de interbloqueos

● Interbloqueo por acceso a recursos.● Interbloqueo de comunicación

● Ocurre con comunicaciones bloqueantes● Más frecuente en sistemas paralelos, por la

comunicación todos con todos. En sistemas distribuidos, cliente-servidor es el esquema dominante, en cuyo caso es muy raro que ocurra

A B Csend(B) send(C) send(A)recv(C) recv(A) recv(B)


Algoritmos de Detección Interbloqueos

● Centralizado. Basado en grafos de espera● Actualización del grafo:

● Cada máquina envía grafo a coordinador. Cada vez que ocurra una variación le notifica.

● Periódicamente cada máquina notifica sus últimos cambios .

● Periódicamente coordinador solicita la información


Algoritmo de detección centralizado

● Interbloqueo no detectado; si coordinador asigna recursos entonces no ocurre.

● Interbloqueo falso. Ejemplo: Se pierden mensajes– Si B solicita a T y C libera a T y llega primero el mensaje

de B al coordinador, entonces cree que hay interbloqueo

S

B

R

A

T

CS

T

CS

B

R

A

Máquina 0 Máquina 1 Coordinador


Algoritmo de Detección Distribuido

● Basado en grafo de recursos y procesos● Asume comunicación confiable● Se permite a procesos (o transacciones) pedir

varios recursos a la vez


Algoritmo de Detección Distribuido

● Cuando un proceso tiene que esperar recurso ocupado, envía mensaje Sonda al que tiene el recurso.● Mensaje contiene: Id proceso que espera, Id

proceso que envía mensaje, Id de proceso que recibe mensaje

● Cuando proceso recibe mensaje Sonda● Si está en espera de otros recursos, agrega los

arcos respectivos. Si hay ciclo entonces hay interbloqueo


Algoritmo de Detección Distribuido: Recuperación

● El proceso que detecta el interbloqueo puede decidir terminar (sucidarse) y liberar sus recursos● Puede inducir a otros suicidios innecesarios● Opción: seleccionar víctima

Documents

Sistemas de Operación II - ldc.usb.vefigueira/cursos/SOPII/Material/Transacciones.pdf · romper reglas integridad de la BD. ... Ejecución concurrente obtiene mismo efecto que ejecución