PDF de programación - Transacciones Distribuidas con ODP.NET 12c

Transacciones Distribuidas con ODP.NET 12c

Por Francisco Riccio



Introducción

Las soluciones empresariales muchas veces tienen el desafío de realizar operaciones sobre múltiples

bases de datos, todas las operaciones ejecutadas deben ser trabajadas y vistas como sola transacción. Si

una operación sobre una base de datos falla, todo el conjunto de operaciones deben ser canceladas.

Asimismo se debe dar conformidad de la transacción si no hay ningún error.

El desafió se presenta más aún cuando cada de base de datos pertenecen a diferentes proveedores,

tales como: Oracle, IBM, Microsoft, etc.

Antes de entrar en detalle sobre la implementación, primero se explicará una breve teoría sobre el

procesamiento de transacciones distribuidas (DTP).

DTP se implementa mediante 3 componentes:

Figura 1



• Application Program (AP), es el responsable de definir el inicio de una transacción distribuida y

responsable de solicitar la aceptación o cancelación de todas las operaciones realizadas. Este

componente es lo que programaremos más adelante mediante una capa de acceso a datos.

• Resource Manager (RM), es una base de datos o cualquier fuente de datos que es utilizada por

un Application Program. En nuestra implementación será una base de datos en Oracle RAC 12c y

SQL Server 2012.

• Transaction Manager (TM), es el servicio responsable de asignar un único ID a una transacción
distribuida, monitorearla y solicitar la confirmación o cancelación de múltiples operaciones que

están asociada a la transacción distribuida. Para este componente utilizaremos Microsoft

Distributed Transaction Coordinator (MSDTC).



1

Las transacciones distribuidas a implementar estarán basadas en el estándar eXtended Architecture

(XA), el cual define el protocolo two-phase commit y la API usada para la comunicación entre el

Transaction Manager y el Resource Manager.

El protocolo two-phase commit permite que una transacción se ejecute en 2 fases. En la primera fase, el

Transaction Manager pregunta a todos los Resource Manager enlistados en la transacción distribuida si

tienen todo listo para realizar una confirmación de las operaciones ejecutadas, si ninguna de estas

reporta algún problema se procede a la segunda fase que es básicamente en confirmar las operaciones.

En caso de algún incidente la transacción entra en estado de duda y es resuelto por el Resource

Manager.

Una transacción queda en estado de duda cuando ocurre los siguientes escenarios:

• Falla en la comunicación de red entre las base de datos enlistadas.

• Alguno de los servidores que participan en la transacción distribuida se cae.

• Algún bug en el software del manejador de base de datos.

El objetivo de nuestra implementación es simular una transacción bancaria donde vamos a tener una

cuenta de ahorros que realizará una transferencia de dinero a otra cuenta. La información de la primera

cuenta de ahorros se almacena en una base de datos Oracle RAC 12c y la segunda en una base de datos

SQL Server 2012. Si alguna de las bases de datos presenta algún problema, la transferencia de dinero

debe ser desechada, manteniendo cada cuenta la misma cantidad de dinero que originalmente tenía

antes de la transacción.

La implementación de la solución se realizará mediante diferentes capas lógicas, permitiendo que cada

componente pueda ser distribuido en diferentes equipos.

Asimismo se entrará en detalle sobre cada componente Oracle que se requiere tener instalado para el

correcto despliegue de la solución como también las consideraciones que debemos tener en un

ambiente Oracle RAC cuando queremos implementar transacciones distribuidas.

Antes de iniciar con explicación de la arquitectura, recomiendo revisar los siguientes URL:



http://www.oracle.com/technetwork/es/articles/dotnet/implementar-aplicaciones-net-1924201-

esa.html

http://www.oracle.com/technetwork/database/options/clustering/overview/index.html

http://docs.oracle.com/cd/B28359_01/win.111/b28377/install.htm#i1007065

http://msdn.microsoft.com/es-es/library/ms731082(v=vs.110).aspx





2

La arquitectura que se diseñó para cumplir con el requerimiento funcional fue el siguiente:

Figura 2





Servidor & Componente

Explicación breve

Oracle RAC 12c

Esta base de datos almacena la información de la cuenta de ahorros que

iniciará la transferencia de dinero hacia otra cuenta. La base de datos se

encuentra en una configuración Oracle Standard RAC 12c y sobre



3

plataforma Oracle Linux 5.10 x64 bits.

Contará con una base de datos llamada PRD el cual presenta un servicio

llamado PRD_XA.

SQL Server 2012

Esta base de datos almacena la información de la cuenta de ahorros que

recibirá la transferencia de dinero. Contará con una base de datos

llamada PRD que se encuentra en una instancia no nombrada.

DNS

Resolverá las IPs de los hostnames solicitados. Asimismo por buena

práctica, será responsable de devolver cualquiera de las 3 IP’s asociadas

al IP SCAN de nuestra configuración de Oracle RAC 12c.

MSDTC

Este servidor tiene instalado el sistema operativo Windows Server

2008R2 acompañado de una configuración básica para habilitar el

servicio de MSDTC con soporte a transacciones XA.

También se ha instalado la versión Oracle Client 12c con la finalidad

instalar el servicio OracleMTSRecoveryService que ayudará al MSDTC a

resolver transacciones dudosas donde las base de datos Oracle esten

participando. El cliente Oracle también es importante porque nos

provee ODP.NET, el cual permitirá que el servidor MSDTC pueda

comunicarse con nuestra base de datos Oracle RAC 12c.

Adicionalmente este servidor presenta un servicio Windows que expone

la lógica de negocio para realizar la transferencia bancaria y el manejo

de la transacción distribuida todo a través de un servicio Windows

Communication Foundation (WCF).

Cliente

La aplicación será una aplicación de escritorio que solo se comunicará

con la capa de negocio ubicada en el servidor MSDTC para ejecutar las

operaciones que requiera. Esta aplicación correrá sobre clientes

Windows, en nuestro caso sobre Windows 7.















4

Implementación

Oracle RAC 12c

Contando con una base de datos en Oracle RAC, es recomendable crear un servicio de base de datos de

tipo singleton si estamos manejando una configuración de servicios manejados por política; si estamos

trabajando servicios administrados por el administrador debe crease el servicio con una única instancia

preferida y las demás de tipo disponible. Para ambos casos, debemos habilitar que el servicio será

usado para DTP.

Ejemplo: En nuestro caso crearemos un servicio manejado por el administrador llamado PRD_XA el cual

tendrá como instancia preferida a la instancia PRD1 y como disponible a PRD2.

Asimismo se ha habilitado el soporte DTP al servicio (Esto mediante la opción -x true).

srvctl add service -d PRD -s PRD_XA -preferred PRD1 -available PRD2 -x true



Procedemos a su validación:





5

Utilizando un servicio con la opción DTP, permite que todas las conexiones de base de datos enlistadas

en una transacción distribuida sean manejadas por una única instancia y cualquier evento de

reubicación del servicio a otro nodo será completamente soportado para DTP, de esta manera Oracle

asegura que se ha hecho la recuperación efectiva de las operaciones que estuvieron pendientes, esto no

ocurre cuando las conexiones hacia la base de datos que están enlistadas en la misma transacción

distribuida se encuentran conectadas en diferentes instancias del Oracle RAC.

Sino cumplimos la recomendación previa, nuestra aplicación conseguirá posiblemente los siguientes

errores en caso de ocurrir un failover del servicio: ORA-24756 (transaction does not exist) / ORA-01591

(lock held by in-doubt distributed transaction).

Es importante mencionar que en una configuración en Oracle RAC contamos con 1 background process

de base de datos por instancia llamado GTX, el cual está configurado por default a un 1 proceso y este

número es regulado automáticamente por Oracle Database dependiendo de la carga que se esté dando.

Asimismo podemos manualmente configurar el número de procesos del background process a través

del parámetro GLOBAL_TXN_PROCESSES.

Nota: Toda transacción distribuida que se ejecuta en una base de datos Oracle demandará un espacio

adicional en el Large Pool de la instancia.



Servicio MSTDC

a) Habilitación del servicio MSDTC para el soporte del estándar XA y Conexiones Remotas.





6







7

Se describe algunas de las opciones:

Acceso a DTC desde la red: permite que el DTC pueda ser accedido desde la red.



Permitir entrantes: permite que una transacción distribuida se origine de manera remota y corra en

el servidor. (En nuestro caso podemos omitir este check ya que la transacción distribuida se

originará en el mismo servidor desde un servicio WCF). Mismo análogo es para la opción Permitir

salientes.

Habilitar transacciones XA: permite habilitar el estándar XA.



b) Instalación del servicio OracleMTSRecoveryService.

El servicio OracleMTSRecoveryService (OraMTS) conversa directamente con el MSDTC con la finalidad de

ayudarlo en mantener la consistencia de la información de las bases de datos Oracle enlistadas en la

transacción distribuida cuando entran en estado dudoso.



8

Este servicio viene como parte de los componentes del Oracle Client.

Es importante que se seleccione la opción Oracle Services For Microsoft Transaction Server 12.10.1.0.





A partir de la versión Oracle Database/Client 12c cada instalación (ORACLE_HOME) mantiene su propio

servicio y debemos crearlo de manera manual con el siguiente comando:

oramtsctl –new



*.- Debemos asegurarnos que nuestras variables de ambiente de la sesión de Windows esté apuntando

al ORACLE_HOME correcto.

Posterio