DB2 9.7: Transacciones autónomas

Qué son, cómo crearlas y ejemplos del mundo real

Conozca las transacciones autónomas, una característica introducida en IBM DB2®Versión 9.7 para Linux®, UNIX®y Windows®. Obtendrá una descripción general y un ejemplo de qué es una transacción autónoma, y cómo crearla.

Yash Manwani, Associate Software Engineer, IBM

Photo of Yash ManwaniYash D. Manwani es Associate Software Engineer en IBM India. Trabaja en IBM desde 2008, y desde que ingresó a la compañía pertenece al equipo de prueba de verificación funcional de DB2 ISL. Todo este tiempo trabajó en aseguramiento de calidad de DB2. Yash es ingeniero en Electrónica y Comunicaciones egresado de la Universidad de Ciencia y Tecnología de Cochin, India.



Mike Springgay, Senior Development Manager, IBM

Photo of Mike SpringgayMike Springgay es Senior Development Manager del equipo de desarrollo de DB2 para Linux, UNIX y Windows. Se sumó al equipo de desarrollo de DB2 en 1997 y actualmente tiene a su cargo las áreas de conectividad cliente-servidor e infraestructura de procedimientos almacenados.



22-12-2009

Introducción

Este artículo presenta las transacciones autónomas, una característica introducida en DB2 9.7. Las transacciones autónomas son de interés tanto para los administradores de bases de datos como para los desarrolladores de aplicaciones.

Este artículo describe a DB2 9.7 para Linux, UNIX, y Windows. Los conocimientos sobre el procesador de línea de comandos (CLP por su sigla en inglés) DB2 y SQL PL son beneficiosos.

Para ejecutar los ejemplos, usted necesita acceder a la base de datos DB2 9.7 para Linux, UNIX, y Windows. Consulte Recursos para descargar una copia de prueba de DB2.


Descripción básica de las transacciones

Las transacciones son entidades del mundo real que se pueden expresar en forma de texto, números, o ambos, para ser procesadas por un sistema de administración de base de datos. Se consideran acciones realizadas en la base de datos y se deben realizar en grupo.

Por ejemplo, una solicitud para transferir un montoXde la cuenta del usuario A, a la cuenta del usuario B es una transacción simple. Esta transacción se puede desglosar en dos instrucciones SQL, como se muestra en la el Listado 1.

Listado 1. Ejemplo de transacción simple
Update table AccountInfo set CurrentBalance =
CurrentBalance - X, where UserName=A Update table AccountInfo set CurrentBalance =
CurrentBalance + X, where UserName=B

Esta transacción sólo se podrá considerar exitosa si las dos instrucciones SQL pudieron actualizar correctamente la tabla. Para asegurarse que ambas instrucciones se hayan aplicado o ninguna lo haya hecho, las aplicaciones se ejecutan de manera tal que no se efectúen cambios a la base de datos hasta que se produzca una CONFIRMACIÓN. En una CONFIRMACIÓN, todas las instrucciones no confirmadas (instrucciones después de la CONFIRMACIÓN final) se aplican conjuntamente, asegurando la integridad de los datos. Esto es parecido a DESACTIVAR el comportamiento de CONFIRMACIÓN AUTOMÁTICA del procesador de línea de comandos (CLP), emitir luego un conjunto de instrucciones y dar luego una CONFIRMACIÓN manual cuando se realizó. Una REVERSIÓN elimina todos los cambios no confirmados. Por lo tanto las instrucciones de CONFIRMACIÓN y REVERSIÓN son importantes bloques de construcción en la implementación de una transacción.


Presentación de una transacción autónoma

Una transacción autónoma tiene su propio alcance de CONFIRMACIÓN y REVERSIÓN para asegurar que su resultado no afecte los cambios no confirmados del llamador. Además, las CONFIRMACIONES y REVERSIONES en la sesión llamante no deberían afectar los cambios que se completaron al finalizar la transacción autónoma propiamente dicha.

Es importante observar que la sesión llamante se suspende hasta que la sesión llamada devuelve el control. El soporte para transacciones autónomas de ninguna manera se debe considerar como soporte para tener sesiones de ejecución paralelas.


Creación de una transacción autónoma

En DB2, las transacciones autónomas se implementan a través de procedimientos autónomos. Un procedimiento almacenado brinda un medio natural de agrupar instrucciones en un bloque. Para crear un procedimiento autónomo, se especifica la palabra clave AUTÓNOMO en la instrucción CREAR PROCEDIMIENTO, como se muestra en la Listado 2.

Listado 2. Ejemplo de instrucción CREAR PROCEDIMIENTO
CREATE OR REPLACE your_procedure_name
LANGUAGE SQL AUTONOMOUS BEGIN do autonomous work ; END

Cuando se invoca un procedimiento autónomo, se ejecuta en su propia sesión para suministrar la independencia requerida para la transacción. Los procedimientos autónomos que se ejecutan exitosamente implícitamente confirman, en tanto que los que no lo logran se revierten. En cualquier caso, la transacción invocante no se modifica.


Análisis de un ejemplo de uso en la vida real

El Banco B quiere asegurarse que cada consulta realizada en una tabla que contenga datos sensibles del cliente se registre adecuadamente. Para lograr este objetivo, los desarrolladores de aplicaciones en el Banco B cuentan con un conjunto de interfaces que pueden usar para acceder a datos sensibles. Cada interfaz se implementa como un procedimiento almacenado. El procedimiento almacenado devuelve la información solicitada de la tabla, mientras que al mismo tiempo ingresa el ID de usuario del empleado que realiza la consulta y el número de cuenta del registro de cliente que se está consultando, con fecha y hora.

Supuestos

El SQL asume todo lo siguiente:

  • Que existe una conexión a la base de datos
  • Que la función Confirmación Automática está desactivada
  • El terminador de la instrucción se configura en%lo cual se realiza ingresando la instrucción en el CLP de DB2db2 +c -td%iniciando a su vez una nueva sesión de CLP de DB2

Inicio

Primero cree las tablas necesarias. Necesitará una tabla que contenga la información sensible del cliente y otra que contenga la información que se registrará cada vez que se acceda a la información sensible. El Listado 3 muestra un ejemplo.

Listado 3. Creación de dos tablas de ejemplo
DROP TABLE customerSensitiveInfo % CREATE TABLE
customerSensitiveInfo(customerAccountNumber integer, amountOverdue integer) % DROP
TABLE log_table % CREATE TABLE log_table(queryingEmployeeID varchar(100),
customerAccNumber integer, when timestamp) % COMMIT %

Siguiente, crear un procedimiento para escribir en la log_table cuando se acceda a la información sensible, como se muestra en el Listado 4.

Listado 4. Escribir en la tabla de registro
CREATE OR REPLACE PROCEDURE log_query (in
queryingEmployee varchar(100), in accNumber integer, in when timestamp) LANGUAGE SQL
BEGIN insert into log_table values (queryingEmployee, accNumber, when); END % COMMIT
%

Una de las interfaces que brinda el Banco B a sus desarrolladores de aplicaciones es un medio para consultar el monto atrasado de una determinada cuenta. El procedimiento get_AmountOverdue primero realiza una llamada al procedimiento de log_query para dejar registrado que accederá a datos sensibles. Luego realiza unaselecciónde la tabla customerSensitiveInfo para obtener el monto atrasado para un determinado número de cuenta. El Listado 5 muestra un ejemplo.

Listado 5. Procedimiento get_AmountOverdue
CREATE OR REPLACE PROCEDURE
get_AmountOverdue(in accountNumber integer, out overdue integer) LANGUAGE SQL BEGIN
DECLARE due integer; DECLARE currentTime timestamp; SET currentTime= CURRENT
TIMESTAMP; CALL log_query(CURRENT USER, accountNumber, currentTime ); SELECT
amountOverdue INTO due FROM customerSensitiveInfo WHERE customerAccountNumber=
accountNumber; SET overdue=due; END % COMMIT %

Después de crear la interfaz get_AmountOverdue, agregue algunos datos de cliente a la tabla InfoSensibleCliente. Luego ejecute la instrucción en el Listado 6 para crear la tabla.

Listado 6. Instrucción para crear la tabla de ejemplo
INSERT INTO customerSensitiveInfo
VALUES(12345, 10000),(12346,20000) % COMMIT %

La tabla resultante contiene la información como se muestra en la Tabla 1.

Tabla 1. CustomerSensitiveInfo
CustomerAccountNumberAmountOverdue
1234510.000
1234620.000

Una vez completada la tabla con los datos y un medio para acceder a ella, se recupera el monto atrasado de la cuenta 12345. Como usted sólo está interesado en visualizar los datos, preferirá hacerlo de manera anónima, emitir una instrucción de reversión inmediatamente después de la llamada para cubrir sus huellas, como se muestra en el Listado 7.

Listado 7. Agregar una instrucción de reversión al código get_AmountOverdue
CALL
get_AmountOverdue(12345, ?) % Value of output parameters --------------------------
Parameter Name : OVERDUE Parameter Value : 10,000 return Status = 0 ROLLBACK
%

Verificar el estado de log_table, que se parece al Listado 8.

Listado 8. The log_table
SELECT * FROM log_table % QUERYINGEMPLOYEEID
CUSTOMERACCNUMBER WHEN 0 record(s) selected.

Según lo esperado, la tabla de registro está vacía porque la transacción que contiene el acceso real a la tabla y la inserción en la tabla de registro se revirtió. Definitivamente éste no es el comportamiento deseado. Agregue la palabra clave AUTÓNOMO al procedimiento log_query, como se muestra en el Listado 9.

Listado 9. El procedimiento log_query con la instrucción AUTÓNOMO
CREATE OR REPLACE
PROCEDURE log_query (in queryingEmployee varchar(100), in accNumber integer, in when
timestamp) LANGUAGE SQL AUTONOMOUS BEGIN INSERT INTO log_table values
(queryingEmployee, accNumber, when); END % COMMIT %

Ahora obtiene el monto atrasado de la cuenta 12345, y revierte la transacción después de hacerlo nuevamente, como se muestra en el Listado 10.

Listado 10. El código get_AmountOverdue con instrucción revertir
CALL
get_AmountOverdue(12345, ?) % Value of output parameters --------------------------
Parameter Name : OVERDUE Parameter Value : 10,000 return Status = 0 ROLLBACK
%

Nuevamente, verificar el estado de log_table, que ahora se parece al Listado 11.

Listado 11. El log_table después de agregar la instrucción AUTÓNOMO
SELECT * FROM
log_table % QUERYINGEMPLOYEEID CUSTOMERACCNUMBER WHEN 98765 12345
2009:05:25:12.00.00.000000 1 record(s) selected.

Esta vez se logra el resultado deseado. Aunque la transacción que leyó la información sensible se revirtió a si misma, se confirman los ingresos a log_table. De esta manera, usted puede mantener un historial de quién accedió a los datos, aún cuando el acceso propiamente dicho no se hubiera confirmado.


Conclusión

Este artículo introdujo el concepto de transacciones autónomas. Ahora usted debería comprender qué es una transacción autónoma y también cómo crear y usar una en DB2.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=458416
ArticleTitle=DB2 9.7: Transacciones autónomas
publish-date=12222009