PDF de programación - Transacciones en InterBase y Firebird

Transacciones en InterBase R y Firebird (0.2.6)

Juan José Rodríguez

Cuenca, España

[email protected]

4 de julio de 2002

Resumen

Este documento presenta una visión general de las transacciones en Sistemas
Gestores de Bases de Datos, y en particular para los servidores InterBase R1 y
Firebird2.

Además de revisar los conceptos básicos de las transacciones, se describen los
parámetros que afectan al comportamiento de éstas en los servidores antes citados.
También se exponen las funciones disponibles a través del Interfaz de Programa-
ción de Aplicaciones (API) para que el desarrollador pueda aprovechar toda la
potencia de las transacciones. Se describen características propias de los servido-
res InterBase y Firebird en las que las transacciones desarrollan un papel destaca-
do, caso de la Arquitectura Multi-Generacional (MGA), el commit en dos fases.
Por último se presentan las transacciones desde el punto de vista del desarrollador
Delphi, a través del componente TIBTransaction que ofrece la biblioteca InterBase
eXpress.

Este documento va dirigido a desarrolladores que hayan utilizado motores de
datos que no dispongan de mecanismos de control transaccional, o aún disponién-
dolos, y no conocen la implementación y funcionamiento que en InterBase tiene
este mecanismo. En especial está orientado a desarrolladores que utilicen herra-
mientas Borland Delphi3 y Borland C++ Builder4, aunque no exclusivamente.

A lo largo del documento se utilizará el término InterBase para referirse indis-

tintamente a InterBase y a Firebird.

Para las cuestiones legales que afectan a la copia, distribución y modificación

de este documento, diríjase a la sección 4 en la página 18.

1InterBase R es una marca registrada por Borland Software Corporation. A partir de este punto, siem-

pre que nos refiramos a InterBase en realidad lo estamos haciendo a InterBase R.
fuente de InterBase R 6.0 liberado por Borland Software Corporation el 25 de Julio de 2000.

2Firebird es un proyecto Open Source, bajo licencia InterBase Public License, basado en el código

3Delphi es una marca registrada por Borland Software Corporation.
4C++ Builder es una marca registrada por Borland Software Corporation.

1

Índice

1. Introducción a las transacciones

1.1. Transacciones: qué son, para qué sirven y cómo se usan .
.
1.2. Parámetros de una transacción .
.
.
1.3. Funciones del API InterBase .
.
.
1.4. TIP, OAT y OIT. Estados de una transacción .
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.

.
.

.
.

.
.

.
.

.
.

2. Concurrencia y otros aspectos

2.1. Arquitectura Multi-Generacional .
.
2.2. Limpiando la base de datos: sweeping, gbak y gfix .
.
2.3. Bloqueos muertos, dead-locks
2.4. Commit en dos fases
.
.
.
.
. .
2.5. Generadores .

. .
. . .

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.

.
.

.

.

.

.

.

.

.

.

.
.
.
.

.
.
.
.
.

.
.

.
.
.
.

.
.
.
.
.

.
.

.
.
.
.

.
.
.
.
.

.
.

.
.
.
.

.
.
.
.
.

.
.

.
.
.
.

. .
. .
. .
. .

.
.
.
.
. .

. .
. .
. .
. .
.

.
.

. .
.
.

3
3
5
7
9

10
10
12
14
15
15

17
17
17

18

19

.

.

.
.
.
.
.

.
.

.
.
.
.
.

.
.

3. Utilizando las transacciones desde Delphi
.

InterBase eXpress (IBX)
.
3.1.1. El componente TIBTransaction .

3.1.

.

.

.

.

.

.

.

.
.

.
.

.
.

.
.

.
.

.
.

4. Licencia

5. Historial

2

1.

Introducción a las transacciones

1.1. Transacciones: qué son, para qué sirven y cómo se usan

Como5 primera aproximación, podríamos definir una transacción como una uni-
dad de trabajo[1] (o procesamiento) que se desarrolla dentro de un contexto atómico.
Es una unidad de trabajo porque el servidor la gestiona como un todo, aunque pue-
da estar constituida por varias operaciones individuales (inserciones, modificaciones o
eliminaciones), contra una o varias bases de datos. Se desarrolla dentro de un contex-
to atómico, de tal forma que todas las operaciones involucradas en la transacción se
confirman, o rechazan, todas en bloque de manera indivisible.

La función básica de las transacciones es garantizar que las operaciones que reali-
zamos contra nuestra(s) base(s) de datos no ponen en peligro la coherencia y consis-
tencia de la información que almacenamos en ella(s).

Profundizando en la definición inicial, podemos decir que los gestores de bases
de datos deben garantizar cuatro propiedades básicas en las transacciones, conocidas
como propiedades ACID[2]:

Atomicidad: Todas las operaciones de una transacción deben ser tratadas como una

única unidad; todas ellas, o ninguna, deben ser ejecutadas.

Consistencia: Una transacción debe llevar la base de datos desde un estado consistente

a otro estado consistente.

Isolation (Aislamiento): Cada transacción se ejecuta como si fuese la única transac-

ción de la base de datos.

Durabilidad: El resultado de una transacción nunca se pierde si ésta finaliza correc-

tamente.

Las transferencias bancarias son un ejemplo típico para poner de manifiesto la razón de
ser de las transacciones. Supongamos que somos clientes de un banco donde tenemos
abierta una cuenta corriente y una cuenta de ahorros. Acabamos de recibir el ingreso
de nuestra paga extra en la cuenta corriente y decidimos transferir parte de la paga a
la cuenta de ahorros; pongamos 500 Euros6. Tras dar la orden oportuna al operario
del banco, éste procede a retirar los 500 Euros de la cuenta corriente (nuestro saldo se
reduce en esa cantidad en esa cuenta), e inicia la transferencia de fondos a la cuenta
de ahorros. Pero, ¡oh, cielos!, en ese preciso instante, justo antes de que la transferen-
cia se lleve a cabo, sucede el desastre. El sistema informático de nuestro banco sufre
un repentino corte de energía, a la vez que nuestro ritmo cardíaco aumenta alarmante-
mente. Nuestros 500 Euros han “volado” de nuestra cuenta corriente, pero nunca han
llegado a nuestra cuenta de ahorros7. En este punto es donde sale en nuestra ayuda el
mecanismo transaccional. En realidad, nuestros 500 Euros nunca han llegado a “volar”

5El título de esta sección es un pequeño homenaje al primer micro-ordenador que adquirí (en realidad
lo compró mi padre), el mítico Sinclair ZX Spectrum 48K. Junto con el ordenador se regalaba un pequeño
libro que enseñaba diversos trucos y técnicas para utilizar en el ZX Spectrum. El título del libro era (es) “ZX
Spectrum. Qué es, para qué sirve y cómo se usa”, de Dr. Tim Langdell. Corría el año 1984, coincidiendo con
otro título famoso, el de la novela de Orwell.

6Desde el día 1 de Enero de 2002, el Euro es la moneda común de doce paises de la Unión Europea, entre

ellos España.

7Cierto, también podría haber ocurrido al revés: primero incrementar el saldo de la cuenta de ahorros y
después decrementar el saldo de la cuenta corriente. Entonces la taquicardia la tendría el operario, pero ...
¿realmente supone que los bancos trabajan así?.

3

de nuestra cuenta corriente, al menos lógicamente, ya que la transacción en la que está
involucrada la transferencia de fondos de una cuenta a otra nunca llegó a finalizar. El
decremento en 500 Euros del saldo de nuestra cuenta corriente está reflejado en la base
de datos, pero no está confirmado. Cuando el sistema se recupere, el operario podrá
continuar la operación donde se había interrumpido, transferir los 500 Euros a nuestra
cuenta de ahorros, o bien cancelar todas las operaciones anteriores e iniciar una nueva
transferencia. En todo caso, la base de datos siempre se ha mantenido en un estado con-
sistente. Nuestros 500 Euros siempre han estado ahí, incluso cuando la transferencia
de fondos se interrumpió a la mitad.

Cómo puede garantizar el servidor la consistencia de la base de datos; es decir,
cómo puede asegurar el mecanismo transaccional que un fallo en el sistema no com-
prometerá la coherencia de la información que almacena la base de datos. Básicamente
existen dos vías para lograr este objetivo: podría utilizar un mecanismo de registro de
operaciones, o bitácora, donde la transacción registra cada uno de los cambios que
lleva a cabo contra la base de datos. Este registro puede hacerse en paralelo con los
cambios reales en la base de datos, de tal forma que ante un fallo del sistema todos
los cambios puedan deshacerse siguiendo el rastro de las operaciones reflejadas en la
bitácora, o bien registrar todos los cambios sólo en la bitácora y confirmarlos poste-
riormente en la base de datos. La alternativa a la bitácora es el mecanismo conocido
como multiversión8. Aunque profundizaremos en la multiversión posteriormente, ade-
lantemos que éste es el método que utiliza InterBase y se basa en generar diferentes
versiones de los registros modificados, asociando cada una de estas versiones a la tran-
sacción que las modifica. El papel que juegan las transacciones en este método para
garantizar la consistencia de la base de datos, así como la concurrencia de múltiples
usuarios, es vital.

El uso de las transacciones para el desarrollador de aplicaciones es extremadamente
simple. Se comienza abriendo la transacción; a continuación se aplican los cambios
(uno o múltiples) que desee contra la base de datos (una o varias), y por último se
confirman (commit) o rechazan (rollback) en bloque los cambios aplicados en el paso
anterior.

En este punto un comentario: si usted es un desarrollador Delphi que ya ha trabaja-
do contra servidores InterBase a través del Borland Database Engine, o de bibliotecas
de componentes tipo InterBase eXpress, InterBase Objects, etc., puede que no se sien-
ta identificado con el método de uso de las transacciones expuesto anteriormente, ya
que usted no precisa abrir la transacción, ni tampoco confirmarla o rechazarla. Bien, es
cierto, ésto es debido a que estos componentes pueden encargarse de gestionar implíci-
tamente las transacciones por usted, aunque también le dejan abierta la posibilidad de
gestionarlas explícitamente.

Un segundo comentario: toda operación contra una (o varias) base(s) de datos In-
terBase siempre está bajo el c