Una
transacción de larga duración (long-running transaction) es aquella cuya
ejecución se realiza en un tiempo relativamente largo y que no necesita de las
capacidades ACID de las transacciones atómicas.
En
este caso el controlador ejecuta un proceso n. Si todo sale bien, persiste los
datos procesados. En caso contrario deshace la persistencia de datos y da paso
a un proceso denominado compensación tratando de devolver el estado inicial del
repositorio a como estaba antes de comenzar la transacción.
El
controlador se encarga también de persistir a su vez el estado de todo el
proceso transaccional ya que no se sabe en que momento exacto este va a
continuar.
Las
transacciones de larga duración pueden permanecer inactivas durante períodos de
tiempo mientras esperan recibir mensajes externos.
DISEÑO DE PROCESOS DE LARGA DURACION COMO TRANSACCIONES
Desde
un punto de vista teórico, un proceso transaccional es algo que no puede quedar
a medias, que debe concluirse de forma exitosa o fallida, en cuyo caso no deben
persistir los datos procesados.
Veamos
el ejemplo típico de una solicitud de préstamo bancario. Este es un proceso que
pasa por múltiples etapas desde su solicitud hasta su aprobación o
desaprobación. Estas etapas incluyen captar al cliente si ya no lo es, crearle
una cuenta, análisis de riesgo teniendo en cuenta sus ingresos y el monto del
préstamo pedido, etc. En cada etapa trabajan diferentes departamentos y
personal de la banca para al final conceder el préstamo o emitir el rechazo a
la solicitud, y cada etapa puede llevar un tiempo más o menos largo en base a
las prioridades de la oficina, carga de trabajo de los empleados, documentación
suministrada por el cliente y otros factores.
Sin
embargo desde el punto de vista lógico y de cara al cliente, sigue siendo un
proceso transaccional: el cliente solo ve el resultado con el esquema de todo
(préstamo concedido) o nada (préstamo denegado), si alguna de las condiciones o
análisis reflejan que el cliente no es apto para recibir el préstamo
solicitado, se termina la transacción y los datos que componen el préstamo no son persistidos
puesto que este no ha llegado a formalizarse.
Una
solicitud de préstamo es un proceso transaccional pero de larga duración.
Posee
consistencia, porque las operaciones para conceder un préstamo pueden terminar
felizmente si los datos son correctos y se ajustan a las condiciones que impone
el banco.
También
posee durabilidad, porque una vez concedido el préstamo se persisten unos datos
que permitirán soportar todo el proceso de amortización del préstamo, las
cuotas que se cobrarán al cliente, los intereses, etc.
La
atomicidad y la consistencia no son estrictas, debido a que no pueden
bloquearse los datos hasta que la transacción termine, de forma tal que otras
transacciones y procesos pueden modificarlos.
Una
transacción de larga duración puede estar formada por transacciones atómicas y
por otras transacciones de larga duración. Las primeras se ejecutan de forma
rápida (crear el expediente de un nuevo cliente o crear una cuenta corriente),
otras se concluyen después de tiempo más o menos largo (solicitud de un
préstamo, solicitud de una tarjeta de crédito o débito). Es muy común que
algunos de los procesos de la transacción sean atómicos y otros de larga
duración.
Por
lo general estas transacciones forman parte de un flujo de trabajo (human
workflow) en el cuál intervienen personas para aprobaciones, autorizaciones o
agentes externos a la entidad.
Otra
característica de este tipo de transacciones es que al margen de que el
resultado sea todo o nada, los procesos u operaciones individuales persisten
los datos o realizan operaciones de COMMIT. Esto se debe a que como la
ejecución es tan demorada en el tiempo,
la transacción debe retomarse en algún punto para poder continuar su
curso normal y en ese momento apoyarse en un estado anterior y utilizar datos
previamente persistidos. Los recursos no se pueden tener bloqueados y hay que
establecer estados intermedios que permitan continuar la ejecución más tarde.
Por
ejemplo, al procesar la solicitud de un préstamo, un primer paso es captar un
nuevo cliente persistiendo sus datos personales (nombre, dirección, DNI,
teléfono, etc.)
Un
segundo paso que puede ser la creación de una cuenta corriente (si no la
tiene), se apoya en los datos anteriormente guardados para ese cliente.
El
proceso transaccional de solicitud de préstamo continua, asentando datos y
guardando el estado en cada una de las operaciones que lo componen.
¿Que
ocurre si al final de la transacción el préstamo es denegado?
Puede
ocurrir que el cliente, no se sienta interesado en pertenecer a la entidad
bancaria que no ha podido resolver su problema y decide marcharse. En este
caso, y a pesar que los datos finales para el préstamo no fueron persistidos
debido a la negativa, es necesario deshacer todos los datos persistidos que
puede que no sean de interés de institución bancaria (en realidad por
normativas de Banco de España se conservan datos de cliente por un período de
varios años).
Imaginemos
que las operaciones que persistieron los datos eran transacciones atómicas. Cumpliendo
con las características ACID, los datos persistidos seguirán guardados a pesar
de que la transacción de larga duración no terminó de forma exitosa para el
cliente.
En
este caso, se activa una nueva operación además del COMMIT y del ROLLBACK. Esta
operación se denomina compensación.
COMPENSACION
La
compensación no es más que deshacer de forma controlada y ordenada los datos persistidos
por una operación.
Cuando
los datos no han sido persistidos aún, o sea, están en almacenamiento temporal
(variables, buffers, áreas de log, objetos, etc.) la operación “no persistirlos”
es el ROLLBACK.
En
teoría, tanto el ROLLBACK como la compensación deben devolver los repositorios
de datos a su estado original, o sea al estado en que se encontraban justo
antes de iniciar la transacción que los persistió a través de operación COMMIT.
La
compensación es un proceso más complejo que un borrado, dado que la
persistencia de datos puede ocurrir en múltiples repositorios y que los datos
por lo general están relacionados entre sí. Esto implica que no solo hay que
borrar datos en un repositorio sino también borrar datos relacionados en otros
repositorios e incluso procesarlos.
Por
lo general el proceso de compensación implica la ejecución de determinadas
reglas de negocio que permiten, si no devolver el estado del repositorio a como
estaba originalmente, anular los efectos de la operación persistida.
Un
ejemplo de banca es como deshacer o cancelar una operación contable errónea,
por ejemplo un cargo domiciliado en nuestra cuenta.
Este
cargo no solo afecta el saldo de la cuenta en cuestión, sino que representa un
ingreso en la cuenta de la entidad que nos hizo el cargo y su vez ha habido
cobro de comisiones por el servicio, o sea se ha realizado contabilidad
personal y contabilidad empresarial.
Deshacer
o compensar este cargo significa entre otras cosas: abonar el monto del cargo
anterior en la cuenta aumentando su saldo,
realizar un cargo en la cuenta de la entidad que lo produjo y deshacer o
realizar nuevos cobros de comisiones. Aquí es donde interviene el proceso de
compensación.
Es
importante comprender que la compensación es una operación que forma parte de
un proceso de varias etapas. Siempre se compensa lo que una etapa previa ha
persistido. Si las etapas previas no han persistido los datos, la operación
correcta es un ROLLBACK.
Recent Comments