Bases de datos orientadas a objetos transacciones tema vi

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema VI

TRANSACCIONES, CONTROL DE CONCURRENCIA, TRANSACIONES ATÓMICAS, PROBLEMAS DE PÉRDIDAS EN LA ACTUALIZACIÓN

El respaldo y la recuperación de Bases de Datos procesadas concurrentemente requiere que los programas de aplicación definan límites de transacciones para el DBMS. Dichos límites se llaman transacciones lógicas o unidades lógicas de trabajo y definen un conjunto de acciones atómicas.

Con la palabra atómico, hacemos referencia a que se ejecutan todas las acciones o ninguna de ellas.

Para comprender la necesidad de atomicidad, vamos a suponer para nuestra clase que un usuario está ingresando datos para un nuevo trabajo y que después de que se han creado varias transacciones, falla el sistema de computadora.

En este caso, se ha introducido a la base de datos una parte de trabajo; cuando el sistema se recupera y el usuario vuelva a ingresar el trabajo, es posible que se hayan duplicado algunas transacciones.

Para evitar que lo anterior suceda, el programa de aplicación puede definir de atomicidad para el DBMS. Los medios con los que esto se hace, varían de un producto DBMS a otro.

En general, antes de procesar transacciones, la aplicación emite un comando start transaction (iniciar transacción) u otro similar.

El programa de aplicación procesa las solicitudes del usuario hasta el punto final lógicamente consiste (por ejemplo: el final del objeto trabajo).

Si todo el procesamiento se ha realizado en forma correcta, el programa de aplicación emitirá un comando end transaction, commit (final de transacción, ejecutar) o algún otro parecido.

En este punto el DBMS hace permanentes todos los cambios en la base de datos.

Si ha existido un problema durante el procesamiento, el programa de aplicación emitirá un comando roll back (recuperación regresiva), lo que indica al DBMS que elimine todos los cambio realizados desde el comando start transaction.

Si el programa de aplicación terminó en forma anormal debido a una falla del sistema o a que el programa se interrumpió de un modo abrupto, no se recibirá un comando end transaction y el DBMS eliminará los cambios provisionales.

Editado por Sandra Pérez Díaz

1

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema VI

Ejemplo Comparación de los resultados de aplicar acciones seriales en contra de una transacción de varios pasos a) Dos de tres actividades completadas exitosamente, dando como resultado anomalías en la base de datos y

b) Ninguna modificación efectuada en vista que la totalidad de la transacción no fue exitosa.

Editado por Sandra Pérez Díaz

2

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema VI

CONTROL DE CONCURRENCIA Se toman medidas de control de concurrencias para asegurar que le trabajo de un usuario no influya negativamente en el de otro.

En algunos casos, estas medidas aseguran que un usuario obtendrá el mismo resultado cuando procesa con otros usuarios, que el que obtendría si estuviera procesando solo.

En otros casos, esto significa que su trabajo se ve influenciado por el de otros, pero de forma anticipada.

Por ejemplo, en un sistema de registro de pedidos, un usuarios debería poder ingresar un pedido y obtener el mismo resultado sin importar que haya otro usuarios, o cientos de éstos.

Por otra parte, un usuario que está imprimiendo un reporte del estado actual del inventario quizá quiera obtener los cambios en el procesamiento de datos de otros usuarios, a pesar de que exista el peligro de que otros cambios sean abortados más tarde.

Desafortunadamente, ninguna técnica o técnica o mecanismo de control de concurrencias es ideal para todas las circunstancias.

Todas implican decidir entre varias alternativas, por ejemplo: un usuario puede lograr un control de concurrencia muy estricto al aplicar locks a la base de datos completa, pero mientras esté trabajando con ésta, nadie más podrá ejecutar nada.

Esta es una protección muy estricta, pero a un precio muy alto.

Editado por Sandra Pérez Díaz

3

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema VI

¿POR QUÉ LA NECESIDAD DE TRANSACCIONE ATÓMICAS? Como mencionamos anteriormente, en la mayoría de las aplicaciones de la base de datos los usuarios transmiten su trabajo en forma de transacciones que también se conocen como unidades lógicas de trabajo.

Una transacción (o LUW) es una serie de acciones que se llevará a cabo en la base de datos, de tal manera que todas se ejecuten con éxito, o que ninguna se realice por completo.

Algunas veces esta transacción se llama atómica, puesto que se ejecuta como una unidad.

De acuerdo a lo anterior, considera la siguiente secuencia de acciones de la base de datos que puede ocurrir cuando se registra un nuevo pedido:  

Cambia el registro del cliente y aumenta Cantidad que Adeuda Cambia el registro del vendedor y aumenta Comisión que se Debe

Editado por Sandra Pérez Díaz

4

[TEMAS SELECTOS PARA LAS BASES DE DATOS] 

Tema VI

Ingresa el nuevo registro de pedido en la base de datos.

Supongamos para nuestra clase, que falla el último paso, quizás porque no hay suficiente espacio en el archivo.

Lo anterior, traería grandes confusiones que habría si se hicieran los dos primeros cambios, pero no el tercero.

Al cliente se le cobraría por un pedido que nunca recibió y un vendedor recibiría la comisión por un pedido que nunca fue enviado.

Obviamente, se necesita considerar estas tres acciones en conjunto (ya que se realicen todas o que ninguna se lleve a cabo).

PROCESAMIENTO DE TRANSACCIONES CONCURRENTES: Cuando se han procesados dos transacciones en una base de datos al mismo tiempo, se les llama transacciones concurrentes.

Aun cuando el usuario le pueda parecer que las transacciones concurrentes se han procesado en forma simultánea, esto no puede ser verdad, ya que la CPU de la máquina que está procesando la base de datos solo puede ejecutar una instrucción a la vez.

Por lo general, las transacciones están mezcladas, lo que significa que el sistema operativo alterna los servicios de la CPU entre las tareas para que alguna parte de cada una de ellas se realice en un intervalo determinado.

Este cambio entre las tareas se realiza tan rápidamente que dos personas usando browsers y sentadas lado a lado procesando la misma base de datos, quizá crean que sus transacciones fueron completas simultáneamente, pero, en realidad, las dos están mezcladas.

La siguiente figura, muestra dos transacciones concurrentes: La del usuario A lee el artículo 100, lo cambia y lo re-escribe en la base de datos.

La transacción del usuario B lleva a cabo las mismas acciones, pero en artículo 200.

La CPU procesa lo del usuario a hasta que encuentre una interrupción I/0 o alguna otra causa de retraso.

El sistema operativo cambia el control al usuario B. La CPU procesa ahora lo del usuario B hasta que encuentre una interrupción, en este punto el sistema operativo pasa el control de regreso al usuario A.

Editado por Sandra Pérez Díaz

5

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema VI

Para todos los usuarios, el procesamiento parece simultáneo, pero en realidad está mezclando, o es concurrente.

PROBLEMA EN PÉRDIDAS EN LA ACTUALIZACIÓN: El procesamiento concurrente anteriormente ejemplificado, no tiene problemas porque dos usuarios están procesando datos diferentes.

Pero supongamos que ambos quieren procesar el artículo 100, por ejemplo: el usuario A quiere ordenar cinto unidades del artículo 100 y el B desea ordenar tres unidades del mismo artículo.

La siguiente figura refleja esta problemática planteada. De acuerdo con el registro existen 10 unidades en inventario. El usuario B lee el registro 100 en otra área de trabajo.

Nuevamente, de acuerdo con el registro existen 10 unidades en inventario.

Ahora el usuario A toma cinto, disminuye la cantidad de elementos en su área de trabajo a cinto y re-escribe el registro para el articulo 100.

Luego el usuario B toma tres, disminuye la cantidad en su área de trabajo a siete y re-escribe el registro para el elemento 100.

La BD ahora muestra, incorrectamente que existen siete elementos en el inventario del elemento 100.

Revisemos: comenzamos con 10 en inventario, el usuario A toma cinto, el usuario B toma tres y la base de datos muestra que hay siete en inventario => Obviamente detectamos un problema.

Editado por Sandra Pérez Díaz

6

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema VI

Ambos usuarios tuvieron datos que eran correctos al momento de obtenerlos. Pero cuando el usuario B leyó el registro, el A ya tenía una copia que estaba por actualizarse.

Esta situación se llama problema de perdida de actualización o problema concurrente en la actualización.

Existen otros problemas similares, llamado problema de la lectura inconsistente. En éste, el usuario A lee información que ha sido procesada por una parte de la transacción del usuario B. Como resultado, el A lee incorrectamente los datos.

Una solución para las inconsistencias causadas por procesamiento concurrente es evitar que aplicaciones múltiples obtengan copias de un mismo registro cuando va a tener cambios.

A esto se le denomina lock (Bloqueo de recursos).

Editado por Sandra Pérez Díaz

7