Aplicaciones operacionales

distribuidas geogrficamente
Mangesh Kasbekar
8 de mayo de 2002
Resumen del coloquio
1. Introduccin y motivacin
2. Problemas con el modelo de aplicacin distribuido
geogrficamente
3. Fundamentos bsicos de las transacciones
4. Puede ser til una reconsideracin de los modelos de aplicacin?
5. Conclusin y P & R
Resumen del coloquio
1. Introduccin y motivacin
2. Problemas con el modelo de aplicacin distribuido
geogrficamente
3. Fundamentos bsicos de las transacciones
4. Puede ser til una reconsideracin de los modelos de aplicacin?
5. Conclusin y P & R
Introduccin y motivacin
Plataforma comn de aplicacin web:
Introduccin y motivacin
El modelo comn de aplicacin web de 3 niveles:
Nivel web para la presentacin de contenido
Nivel medio para la tramitacin de solicitudes y la lgica de negocios
Nivel de base de datos para informacin y transacciones continuas
Introduccin y motivacin
Una aplicacin web tpica en un sitio de comercio electrnico
SA BD
SW
S1
S2
Id elem. Nombre Color
Transaccin:
Seleccione * de los productos donde el
Nombre = `shirt y el Color = blue
Introduccin y motivacin
Problemas con aplicaciones centralizadas
Cuestiones de fiabilidad:
nico punto de fracaso
Un nico fallo puede afectar potencialmente a miles de usuarios
simultneos
Cuestiones de disponibilidad:
Los problemas de particin o conectividad de Internet pueden
hacer que el sitio sea inalcanzable desde alguna parte de Internet
El volumen alto de trfico inesperado puede saturar los enlaces de red
El rendimiento del sitio, tal y como lo ven los usuarios finales, es impredecible
Introduccin y motivacin
Introduccin y motivacin
Una solucin:
Reproduccin y distribucin geogrficas del sitio
Servidores
de borde
Servidor
de origen
Introduccin y motivacin
Los servidores de borde ejecutan el nivel web
Los servidores de borde ejecutan el nivel web y el nivel medio
Reproduccin completa del sitio: todos los servidores
de borde contienen los tres niveles de la aplicacin, con
bases de datos reproducidas.
Los servidores de borde ejecutan el nivel web, el nivel medio
y poseen una cach de base de datos, no una base de datos
completa
Introduccin y motivacin
Otros ejemplos de aplicaciones distribuidas geogrficamente
Utilizacin de servicios web disponibles en algn punto de Internet
Informtica de red, utilizando ciclos libres de mquinas para el
clculo en el mbito global
Introduction and Motivation
Requisitos bsicos para las aplicaciones distribuidas
exactitud
como mnimo, el mismo nivel de rendimiento
como mnimo, el mismo nivel de fiabilidad
mejor disponibilidad
Otros requisitos
seguridad
control
manejabilidad
Resumen del coloquio
1. Introduccin y motivacin
2. Problemas con el modelo de aplicacin distribuido
geogrficamente
3. Fundamentos bsicos de las transacciones
4. Puede ser til una reconsideracin de los modelos de aplicacin?
5. Conclusin y P & R
Problemas con el modelo
Problemas:
Una plataforma muy poco fiable
Las transacciones y la inescalabilidad de esquemas
de reproduccin de bases de datos
La consistencia de las rplicas de aplicacin
Por ltimo, el teorema CAP
Problemas con el modelo
Plataforma:
Latencias, prdidas y congestiones muy elevadas:
tiempo de respuesta de latencias de 20ms a 1000ms
2% a 20% de prdida de paquetes
Enrutamiento no satisfactorio/routers mal configurados
Los pases asiticos se conectan a travs de Los ngeles
De Nepal a Bombay, alrededor del mundo
Divisiones frecuentes de la Red
Comparar con un entorno LAN/Server farm (agrupacin centralizada de servidores)
Problemas con el modelo
Reproduccin de bases de datos:
Esquema rpido: las actualizaciones de todas las transacciones
se propagan a todas las rplicas antes de poder ser ejecutadas
Consistencia estricta entre las rplicas
Imposibilidad de escala; exceso de comunicacin
Se bloquea durante las divisiones de red
El peligro de interbloqueo es alto
Esquema lento: la actualizacin de las transacciones se ejecuta
sin actualizaciones de propagacin, y las actualizaciones se
propagan a las rplicas de forma muy lenta
Consistencia dbil entre las rplicas
Alto grado de colisiones entre transacciones, a menudo se necesita una compensacin
Problemas con el modelo
Problemas con las transacciones en zonas extensas:
Transacciones ms largas: utilizacin deficiente de recursos
Sin autonoma: si no hay un coordinador disponible, no se puede
ejecutar una transaccin
El protocolo 2PC detecta todos los problemas por medio de tiempos lmite:
Mayor oportunidad de fallos debido a las divisiones
Tiempos lmite ms largos
Mayor tiempo de bloqueo para los participantes
Mayores oportunidades de decisiones de compromiso heurstico
Problemas con el modelo
Consistencia de las rplicas de aplicacin
Aplicaciones con alta capacidad stateful (configuracin predeterminada)
Es necesario reproducir el estado para evitar los fallos en los
sitios individuales
Es necesario mantener una consistencia en las rplicas en el caso
de que si un usuario individual es atendido por dos mquinas
diferentes en una nica sesin no haya inconsistencias.
Actualizaciones rpidas
Actualizaciones lentas
Problemas con el modelo
El denominado teorema CAP:
Consistencia
Tolerancia a las
divisiones
de red
Disponibilidad
Teorema:
Se pueden tener como mximo dos de tres
Ej.
Las bases de datos de grupos escogen A y C
DNS escoge A y P
Problemas con el modelo
Por fin, algunas buenas noticias
Para las aplicaciones de red,
Un alto porcentaje de los accesos de las bases de datos
son transacciones de slo lectura (no es necesaria una
propagacin de actualizacin de las rplicas)
Como un amplio volumen de datos est cambiando lentamente,
el caching de las bases de datos del borde puede ser de ayuda
Un buen porcentaje de escritos no entran en conflicto
(nico autor)
Resumen del coloquio
1. Introduccin y motivacin
2. Problemas con el modelo de aplicacin distribuido
geogrficamente
3. Fundamentos bsicos de las transacciones
4. Puede ser til una reconsideracin de los modelos de aplicacin?
5. Conclusin y P & R
Fundamentos bsicos del procesamiento de transacciones
Propiedades de las transacciones
Propiedades ACID
Capacidades de serializacin y de recuperacin
Niveles de aislamiento
Fundamentos bsicos del procesamiento de transacciones
Qu es una transaccin?
Una accin de software compuesta que se inicia con una
orden begin , realiza varias operaciones read/write s
en los datos y finaliza bien con una orden commit o con
una orden abort . Ejemplo:
Begin, r(x), r(y), w(x,1), w(y,0), commit.
Begin, r(x), w(x,2), r(y), r(z), abort.
Fundamentos bsicos del procesamiento de transacciones
Propiedades ACID de una transaccin:
- Atomicidad
- Consistencia
- Aislamiento
- Durabilidad
Fundamentos bsicos del procesamiento de transacciones
Atomicidad:
propiedad de todo o nada
Begin, r(x), r(y), w(x,1), w(y,0), commit.
Begin, r(x), r(y), w(x,2), w(y,1), r(z),
abort.
Fundamentos bsicos del procesamiento de transacciones
Consistencia:
Cualquier conjunto de transacciones que se ejecute simultneamente
no dejar la base de datos en un estado inconsistente.
Begin, r(x), r(y), w(x,1), w(y,0), commit.
Begin, r(x), r(z), w(x,5), w(y,10), commit.
Fundamentos bsicos del procesamiento de transacciones
Aislamiento:
Una transaccin no interferir en la ejecucin de otra transaccin
que se est realizando simultneamente.
Begin, r(x), r(y), w(x,1), w(y,0), abort.
Begin, r(x), r(z), w(x,5), w(y,10), commit.
Fundamentos bsicos del procesamiento de transacciones
Durabilidad:
Persistencia de datos despus de una confirmacin (commit).
Begin, r(x), r(y), w(x,1), w(y,0), commit.
Fundamentos bsicos del procesamiento de transacciones
Ejemplo : transferencia de dinero entre dos cuentas bancarias
function Transfer ( from , to , amount ) {
begin transaction ;
if ( from.balance < amount ) {
abort transaction ;
return ;
}
from.balance -= amount ;
to.balance += amount ;
commit transaction;
}
Fundamentos bsicos del procesamiento de transacciones
Las transacciones ACID son serializables:
Cuando un conjunto de transacciones se ejecuta simultneamente, sus operaciones
pueden ser intercaladas. La ejecucin concurrente se establece por un historial
(que no es nada ms y nada menos que una orden parcial de operaciones).
Un historial es serializable en vistas (view-serializable) si existe una ejecucin
serial posible de las operaciones, de tal forma que, en ambas ejecuciones (tanto
concurrentes como seriales), cada transaccin lee los mismos valores y los
valores finales de la base de datos son iguales.
Un historial es serializable en conflicto (conflict-serializable) si existe una ejecucin
serial posible de las operaciones, de tal forma que, en ambas ejecuciones (tanto
conscurrentes como seriales), el orden de las operaciones en conflicto es el mismo.
Fundamentos bsicos del procesamiento de transacciones
Capacidad de recuperacin:
Para poder mantener una exactitud de la presencia de fallos, es
necesario que los historiales de ejecucin sean recuperables
adems de serializables. No todos los historiales son recuperables.
Un historial es recuperable si cada transaccin se confirma
despus de la confirmacin de otras transacciones a partir
de las cuales ley.
Un historial recuperable evita las cancelaciones en cascada si
lee valores escritos nicamente por transacciones confirmadas.
Fundamentos bsicos del procesamiento de transacciones
Por qu es importante todo esto?
Porque incluso si se reproducen las bases de datos, las
las transacciones deben satisfacer todas estas propiedades,
lo que dificulta la reproduccin de una base de datos.
Fundamentos bsicos del procesamiento de transacciones
Referencias excelentes para el procesamiento de transacciones y los sistemas de bases de datos:
Transaction Processing, de Jim Gray y Andreas Reuter
Concurrency control and recovery in database systems, de Phil
Bernstein et. al. (disponible en Internet)
Resumen del coloquio
1. Introduccin y motivacin
2. Problemas con el modelo de aplicacin distribuido
geogrficamente
3. Fundamentos bsicos de las transacciones
4. Puede ser til una reconsideracin de los modelos de aplicacin?
5. Conclusin y P & R
Modelos de aplicacin optimistas
Es posible que no se puedan llevar a cabo las mismas aplicaciones sin
modificar en una plataforma distribuida geogrficamente, y conseguir el
mismo nivel de rendimiento y fiabilidad.
1. Pueden ayudar las tcnicas habituales como el caching y la particin?
2. Se puede reconsiderar el modelo de aplicacin para que los servidores sean stateless?
3. Se puede reconsiderar el modelo de aplicacin para reducir las necesidades de
consistencia? Si el requisito de consistencia de la aplicacin es bajo, el teorema CAP
no puede ser perjudicial. Podemos optar por la consistencia en detrimento de alguna
otra ventaja?
Modelos de aplicacin optimistas
El caching (almacenamiento en cach) de datos en los servidores
de borde (Proyecto DBCache de C. Mohan, en IBM Almaden)
Puesto que una buena parte de los datos es de slo lectura y cambia
lentamente, el caching en el borde puede proporcionar buenas tasas de
aciertos. Por ejemplo, si los datos de catlogo se almacenan en la cach de
borde, navegar por el catlogo puede tener lugar casi totalmente en el borde.
Son necesarios analizadores de contenido de consultas para determinar
si se puede responder a una pregunta dada desde el cach.
Transacciones RW, actualizar en cualquier lugar, invalidaciones de cach?
Modelos de aplicacin optimistas
Hacer que los servidores de borde sean stateless (descubrimiento automtico)
El estado de sesin de los clientes vuelve a los servidores stateful
(configuracin predeterminada). Si se retira de los servidores el
estado por sesin, pueden volverse menos stateful.
Los ordenadores personales son bastante potentes. Se puede
ampliar el modelo de plataforma para incluir tambin las mquinas
de los clientes? (los sistemas peer-to-peer lo hacen as)
Con el estado del cliente en la mquina del cliente, se reduce el
tamao del estado del servidor.
Modelos de aplicacin optimistas
Datos de particin en lugar de reproduccin:
Cada servidor de borde posee una particin de datos, cuya modificacin local no puede
tener un conflicto global. sta hace que los servidores de borde sean autnomos.
Por ejemplo, en una aplicacin de librera, un servidor de borde recibe una
cantidad de libros para vender. Todas las transacciones necesarias para la
venta de estos libros son ahora transacciones locales y no tienen efecto global.
Por ejemplo, una aplicacin de reservas de viajes basada en servicios web
(transacciones interactivas HPL)
Modelos de aplicacin optimistas
Aplicacin de reservas de viajes basada en servicios web
(transacciones interactivas HPL)
servicio web de Hertz
servicio web de Hilton
servicio web de USAir
Aplicacin de
reserva de viajes
sitio de origen, USAir
sitio de origen, Hilton
sitio de origen, Hertz
Modelos de aplicacin optimistas
Dos tipos de transacciones:
Pesimista
Transacciones que nunca se ejecutarn con optimismo.
Por ejemplo, la transferencia de dinero entre dos cuentas.
Optimista o semi optimista
Algunas transacciones que pueden ser ejecutadas sin mucha
preocupacin. Por ejemplo, una librera vende una copia del
libro de Harry Potter, cuando tiene muchas existencias.
Algunas transacciones se pueden ejecutar con optimismo, lo
que puede provocar una inconsistencia, pero se puede tolerar
o compensar esto. Por ejemplo, vendiendo billetes de avin.
Modelos de aplicacin optimistas
En cada ejemplo se necesita evaluar el modelo de transaccin
optimista en relacin a:
La preservacin de propiedades ACID de extremo a extremo
La serializabilidad y recuperabilidad global de las transacciones
La relacin entre los niveles de aislamiento y de optimismo
Resumen del coloquio
1. Introduccin y motivacin
2. Problemas con el modelo deaplicacin distribuido
geogrficamente
3. Fundamentos bsicos de las transacciones
4. Puede ser til una reconsideracin de los modelos de aplicacin?
5. Conclusin y P & R
Conclusiones
En este coloquio,
Se han presentado las cuestiones derivadas de la distribucin de aplicaciones transaccionales
en una plataforma de servidor distribuida geogrficamente. Las reproducciones de bases
y de transacciones en Internet son difciles, y los sistemas que las necesitan es probable que
ofrezcan un bajo rendimiento y una baja disponibilidad.
El teorema CAP establece que es lo que se puede y no se puede conseguir.
Se puede proyectar la aplicacin cuidadosamente para que pueda ser ejecutada
en una plataforma distribuida geogrficamente
Se puede reocnsiderar el modelo de aplicacin y proponer un modelo
optimista que supere al teorema CAP.
Conclusiones
Temas interesantes sobre los que reflexionar
Las aplicaciones distribuidas geogrficamente pueden ser igualmente fiables
y tener un rendimiento similar a las aplicaciones tradicionales que se ejecutan
en un entorno de agrupacin de servidores (server farm) centralizada?
El caching de bases de datos y la complejidad de los analizadores de
contenido de consultas.
Un modelo de extremo a extremo para transacciones optimistas en
las aplicaciones distribuidas geogrficamente, y que proporcione las
propiedades de las transacciones y del sistema TP utilizando este
modelo.
Resumen del coloquio
1. Introducciny motivacin
2. Problemas con el modelo de aplicacin distribuido
geogrficamente
3. Fundamentos bsicos de las transacciones
4. Puede ser til una reconsideracin de los modelos de aplicacin?
5. Conclusin y P & R
P & R
Diapositivas de reserva
Fundamentos bsicos del procesamiento de transacciones
ste ha sido un ejemplo didctico de transacciones de ejecucin larga
El modelo de transaccin plana no es apropiado para este tipo
- Si se utiliza una nica transaccin para toda la operacin:
- Todos los bloqueos de cuenta se mantendrn hasta la confirmacin
- Cualquier fallo provocar la cancelacin de toda la transaccin y
se perder todo el trabajo realizado.
- Si se utiliza una transaccin para cada depsito de inters
- Exceso de sobrecarga (overhead) por transaccin
Fundamentos bsicos del procesamiento de transacciones
Ejemplo n 3: reserva de viajes.
1. Consiga la fuente, el destino y las fechas del viaje del
cliente.
2. Inicie la transaccin.
3. Consulte la base de datos de la compaa area, consiga una
lista de los precios y la disponibilidad de los vuelos.
4. Consulte la base de datos de empresas de alquiler de coches,consiga
una lista de los precios y la disponibilidad de los coches.
5. Consulte la base de datos del hotel, consiga una lista de
los precios y la disponibilidad de las habitaciones.
6. Reserve los billetes segn la eleccin del cliente.
7. Cuando haya reservado todo, confirme (commit) la transaccin o, en
caso contrario, canclela (abort).
Fundamentos bsicos del procesamiento de transacciones
Este es un ejemplo didctico de una transaccin distribuida/
de mltiples bases de datos.
El modelo de transaccin plana no es apropiado en este caso
- Bases de datos autnomas
- La confirmacin de las transacciones externas depende de
la confirmacin de las transacciones internas
- Si falla una de las transacciones, es posible que sea necesario
cancelar otras transacciones que hayan sido confirmadas.
Fundamentos bsicos del procesamiento de transacciones
Modelos avanzados de transaccin:
1. Transacciones planas con puntos de salvaguarda (savepoints)
2. Transacciones encadenadas
3. Sagas
4. Transacciones anidadas (nested)/de multinivel
Fundamentos bsicos del procesamiento de transacciones
Transacciones planas con savepoints:
Escribir peridicamente el estado de la transaccin en un savepoint.
De esta forma, si se da un fallo en el sistema, la transaccin se puede
revertir al estado de "guardada" y reiniciar desde este estado, en lugar
de cancelar la transaccin completa. Esto reduce la cantidad de trabajo
que se pierde debido al fallo.
Los savepoints pueden ser voltiles o persistentes. Los primeros son
ligeros, pero no sobreviven a accidentes del sistema.
Fundamentos bsicos del procesamiento de transacciones
Transacciones encadenadas:
Las transacciones back-to-back, en las que el contexto de la transaccin
y los bloqueos se pueden pasar de una transaccin a otra.
Begin, r(x), w(x), chainWork, r(z), w(z), commit.
Fundamentos bsicos del procesamiento de transacciones
Saga:
Una saga est compuesta por un conjunto de transacciones T1..Tn y
un conjunto de transacciones de compensacin C1..Cn, y garantiza
lo siguiente:
- Si todas las transacciones tienen xito, el resultado de ejecutar la saga
es el mismo que el de ejecutar T1, T2, ..Tn de forma secuencial.
- Si falla cualquier transaccin Ti, el resultado es lo equivalente a ejecutar
T1, T2, .. Ti, Ci, C2, C1.
Fundamentos bsicos del procesamiento de transacciones
Transacciones anidadas (nested)/de multinivel
Las transacciones de nivel superior continen mltiples subtransacciones.
Las subtransacciones no poseen la propiedad de durabilidad.
La transaccin de nivel superior solamente se confirma cuando se confirman
todas las subtransacciones. La salida de las subtransacciones no ser vlida
hasta despus de la confirmacin de la transaccin superior.
Si se cancela la transaccin de nivel superior, las acciones de las
subtransacciones confirmadas se anularn.
Introduccin y motivacin
Posicin distribuida geogrficamente
SW SA
Idelemt. Nombre Color
S1
S2
BD
Introduccin y motivacin
Para que una aplicacin web se pueda distribuir geogrficamente,
se debe eliminar el fuerte emparejamiento entre AS y DB.
Una forma de hacerlo:
Atenuar los requisitos de consistencia de las aplicaciones y
emplear transacciones optimistas.
Introduccin y motivacin
Visualizacin rpida:
Una arquitectura para las transacciones optimistas distribuidas geogrficamente
SA
BD
E1
E2
S1
N cuenta Saldo Nombre
Introduccin y motivacin
Trabajo relacionado:
Transacciones conversacionales de HP Labs para e-servicios
Sistemas de ficheros distribuidos (como por ejemplo AFS)
Sistemas multiprocesadores de memoria compartida y sus
modelos de consistencia
Resumen del coloquio
1. Introduccin y motivacin
2. Fundamentos bsicos del procesamiento de transacciones
3. Una arquitectura para transacciones optimistas
4. Conclusiones
5. P & R
Fundamentos bsicos del procesamiento de transacciones
Operaciones subyacentes de bases de datos:
El cliente enva:
Begin, r(x), w(x,500), w(y,550), Commit.
La base de datos realiza:
Begin,
readLock(x), read(x),
writeLock(x), updateLog(x), write(x,500),
writeLock(y), updateLog(y), write(y,550),
prepareToCommit, unlock(x), unlock(y), commit.
Este es un ejemplo didctico de una transaccin plana con bloqueo
completo de 2 fases y registro de operacin.
Fundamentos bsicos del procesamiento de transacciones
Ms propiedades de las transacciones:
Historial de transacciones
Serializabilidad
Recuperabilidad
Niveles de aislamiento
Fundamentos bsicos del procesamiento de transacciones
Historiales de transacciones:
Cuando se ejecuta simultneamente un conjunto de transacciones,
sus operaciones pueden ser intercaladas. La ejecucin concurrente
se establece por un historial, (que no es nada ms y nada menos
que una orden parcial de operaciones).
T1 = r1(x) -> w1(x) -> c1 ;
T2 = r2(x) -> w2(y) -> w2(x) -> c2 ;
T3 = r3(y) -> w3(x) -> w3(y) -> w3(z) -> c3 ;
Fundamentos bsicos del procesamiento de transacciones
Un historial completo de estas transacciones es el siguiente:
r2(x) -> w2(y) -> w2(x) -> c2 ;
| |
H1 = r3(y) -> w3(x) -> w3(y) -> w3(z) -> c3 ;
|
r1(x) -> w1(x) -> c1 ;
Fundamentos bsicos del procesamiento de transacciones
Un historial es serializable en vista (view-serializable) si existe una
ejecucin serial posible de las operaciones, de tal forma que, en ambas
ejecuciones (tanto concurrentes como seriales), cada transaccin
lea los mismos valores y los valores finales de la base de datos
sean los mismos.
Un historial es serializable en conflicto (conflict-serializable) si existe
una ejecucin serial de las operaciones, de tal forma que, en ambas
ejecuciones (tanto concurrentes como seriales), el orden de las
operaciones en conflicto sea el mismo.
Fundamentos bsicos del procesamiento de transacciones
Historiales recuperables
Para poder mantener la exactitud en la caso de que se den
fallos, es necesario que los historiales de ejecucin sean
recuperables adems de serializables.
Historiales recuperables
Historiales recuperables que evitan cancelaciones en cascada
Historiales completos
Fundamentos bsicos del procesamiento de transacciones
Un historial H es recuperable siempre que Tj lea de Ti,
donde
- tanto Ti como Tj H
- y Cj H
- y Cj < Ci
Intuitivamente, un historial es recuperable si cada transaccin
se confirma (commit) despus de que se hayan confirmado
otras transacciones de las cuales lee.
Fundamentos bsicos del procesamiento de transacciones
Se dice que un historial H evita las cancelaciones en cascada
siempre que Tj lea de Ti, donde
- tanto Ti como Tj H
- y Cj < Ri(x)
Intuitivamente, un historial evita las cancelaciones en cascada si
lee valores escritos nicamente por transacciones confirmadas.
Fundamentos bsicos del procesamiento de transacciones
Se dice que un historial H es completo
siempre que Wj(x) < Oi(x),
o Abort(j) < Oi(x) o Commit(j) < Oi(x)
Intuitivamente, un historial es completo si no se lee ni escribe
ningn elemento hasta que finaliza la transaccin anterior que
escribi ese elemento, bien confirmndola o cancelndola.
Fundamentos bsicos del procesamiento de transacciones
Niveles de aislamiento
Diferentes nombres de bloqueo
Dependencias inapropiadas entre transaccciones:
Prdida de actualizacin (lost update)
- secuencia write-write
Lectura sucia (dirty read)
- T1 lee un objeto escrito anteriormente por T2, y T2 lo
modifica de nuevo
Lectura irrepetible
- T1 lee dos veces un objeto y consigue dos valores diferentes
Fundamentos bsicos del procesamiento de transacciones
Nivel 3 de aislamiento (lectura repetible)
- Aislamiento verdadero
- No hay prdidas de actualizaciones y las lecturas son repetibles
Nivel 2 de aislamiento (estabilidad de cursor)
- Protege contra dependencias w->w and w->r, pero ignora la dependencia
r->w
- No hay prdidas de actualizaciones ni lecturas sucias
Nivel 1 de aislamiento (aislamiento de navegador)
- Desactiva el aislamiento w->r
- No hay prdidas de actualizaciones
Nivel 0 de aislamiento (anarqua)
- No sobreescribe los datos sucios de otros si stos son de nivel 1 o superior.
Fundamentos bsicos del procesamiento de transacciones
Por qu es importante todo esto?
Porque cualquier sistema optimista TP que se disee debera
proporcionar garantas de que puede apoyar algunas de esas
propiedades de las transacciones (o todas).