Sistema transaccional
Una transacción es el conjunto de operaciones de escritura que se realizan contra una base de datos que únicamente tienen sentido como unidad. Es decir, serán correctas en el caso de que todas las operaciones se hayan efectuado con éxito y serán incorrectas en el caso de que alguna de ellas no se produzca debido a un error.
En el desarrollo de aplicaciones empresariales, la seguridad de la información es uno de los apartados más críticos. No olvidemos que el valor de la información es muy superior al de las aplicaciones.
Por este motivo uno de los apartados básicos en cualquier base de datos es la gestión de transacciones. Seguramente te habrás encontrado con bases de datos en las que la gestión de transacciones requiere una programación manual en la que debes encargarte de los COMMIT y los ROLLBACK.
Nunca debemos de perder de vista el impacto que puede ocasionar en una aplicación una mala gestión de los bloqueos de registros. Dependiendo de la base de datos, estos bloqueos pueden ser a nivel de tabla completa, bloques de registros, registro o incluso a nivel de campo.
Con Velneo podemos olvidarnos de la programación de transacciones ya que éstas se gestionan de forma automática, tanto la transacción como los bloqueos. La base de datos de Velneo cumple las propiedades ACID para la gestión de transacciones seguras. En el caso de las transacciones el servidor las crea, destruye y deshace en caso de no finalizar correctamente, todo sin necesidad de escribir una sola línea de código. Además gestiona las transacciones de forma individual por cada tarea, incluso si un usuario está ejecutando múltiples tareas cada una de ellas es tratada de forma individual pudiendo deshacer una con independencia de que las demás terminen correctamente.
Velneo detecta las operaciones que escriben en disco y las engloba automáticamente en transacciones sin que tenga que intervenir el usuario. Esto permite que, si por el motivo que sea, durante la ejecución de transacciones se produce una detención inesperada o un reinicio del servicio VATP, el sistema al volver a iniciar el servicio, sepa qué transacción o transacciones están pendientes de finalizar y las deshace (ROLLBACK) volviendo al estado anterior a su realización y avisando de este suceso en el visor de sucesos del sistema operativo.
Al deshacerse una transacción la tabla o tablas afectadas serán restablecidas a como estaban antes de iniciar la transacción, garantizando así la integridad referencial de la base de datos y, solamente en el caso de que este cambio implique cambio en el fichero de índices, el sistema procederá a su regeneración.
Si se produce un fallo durante el proceso de reparación de la base de datos, el sistema es capaz de reconocerlo y podrá volver a realizar la reparación cuando se proceda de nuevo al iniciar el servicio VATP.
Cuando se cambia la estructura de una tabla, el servidor renombra el fichero de datos (*.dat) a (*.old), crea un nuevo fichero con la extensión (*.dat) y comienza a pasar los buffers de información hasta completar el traspaso de toda la información a la nueva estructura.
Si durante este proceso el sistema sufre alguna caída, de forma automática, detectará que la regeneración anterior no había finalizado correctamente, por lo que procederá a crear un nuevo (*.dat) y volverá a pasarle toda la información.
Aunque se produzcan múltiples caídas, el fichero (*.old) permanecerá en disco hasta que pueda completar con éxito el traspaso de todos los registros a la nueva estructura.
Si durante la regeneración de índices de una tabla se produce una caída del sistema, Velneo vServer controlará que el proceso no ha finalizado correctamente y, al volver a iniciar el servicio vatp, regenerará de nuevo los índices de la tabla cuyo proceso había quedado interrumpido.
Si el sistema volviese a sufrir una caída nuevamente durante la regeneración de índices, al volver a arrancar el servicio vatp comenzará nuevamente su regeneración.
El sistema transaccional contempla el control del denominado abrazo de la muerte, que no es otra cosa que resolver el conflicto que se produce cuando dos procesos transaccionales se esperan mutuamente, porque bloquean la misma o las mismas fichas, y no pueden continuar. El servidor lo detecta, deshace una de las transacciones y deja continuar a la otra, a continuación reintenta la ejecución del proceso cuya transacción deshizo, y si tras varios intentos le resulta imposible su ejecución, notifica al usuario de la imposibilidad de ejecutar la tarea. Todo esto sin necesidad de escribir ninguna línea de código.
Por último, el gestor de bloqueos de Velneo también es automático y realiza el control de los mismos aplicando una técnica mixta denominada bloqueo blando y bloqueo duro. Ver el capítulo dedicado al Sistema de bloqueos para ampliar la información al respecto.
Si desde un proceso que no transacciona ejecutamos tres procesos que transaccionan:
Procso1
Proceso2
Proceso3
Y en el proceso 2 deshacemos transacción:
Deshacer transacción
Set retorno proceso = NO
Las transacciones de Proceso3 se ejecutarán igualmente.
Pero si la transacción de Proceso2 se deshace por un bloqueo, entonces el proceso se cancelará y el proceso principal también, finalizando su ejecución y, por tanto, no se ejecutará Proceso3.
Una transacción desatendida se produce cuando se inicia una transacción y al cabo de cierto tiempo no realiza operaciones, ni crea registros ni los modifica, etc. El servidor entiende que ha sucedido algún error con esa transacción y la deshace de forma automática al cabo de un tiempo.
Esto puede venir motivado porque durante un proceso se haya solicitado información al usuario final y esté esperando respuesta durante demasiado tiempo, se haya cortado la conexión, etc. El servidor en esos casos ha de deshacer la transacción iniciada.
Esto es debido a que un proceso que realiza operaciones en disco, es decir, modifica registros de las tablas, ha de bloquearlos durante todo el tiempo dure la transacción, siendo desbloqueados al finalizar; y el servidor debe desbloquearlos a fin de que otros usuarios tengan acceso a esos mismos registros, por lo que deshará una transacción desatendida, teniendo en cuenta ciertos parámetros.
Si la transacción está detenida pero el usuario que la ha generado sigue conectado (por ejemplo porque durante un proceso se ha solicitado información al usuario final y esté esperando respuesta, porque el proceso debe realizar otras operaciones que no implican escritura en disco, etc.), el sistema no la deshará hasta pasadas unas horas.
Si la transacción está detenida porque el usuario ha perdido la conexión con el servidor, el sistema la deshará pasados unos minutos.
Se encarga de mantener la ejecución de procesos enviados al servidor (tercer plano), manteniendo la conexión durante la ejecución del proceso.
Si el servidor deja de establecer el hilo de control con el cliente que ha enviado el proceso, pasados 10 minutos considerará que existe un problema y que el cliente se encuentra desenganchado y sin control, por lo que finalizará el proceso y deshará la transacción y por ende las operaciones realizadas. De esta forma, no se bloquean de forma innecesaria registros, ni se realizan operaciones que en determinados casos requerirán control o gestión por parte del cliente y que éste reciba respuesta, de forma similar a como se tratan las transacciones desatendidas (añadir aquí enlace con Transacciones desatendidas).
Este entretenedor se gestiona de forma automática, no requiere programación al igual que el resto del sistema transaccional. El sistema transaccional automático precisamente se encarga de mantener los procesos en tercer plano. Esto incluye procesos lanzados desde altas, modificaciones y bajas, triggers, subprocesos y modificaciones no aseguradas (modificaciones que no abren transacción hasta realizar la modificación: formularios de alta y modificación, rejillas editables, etc.).
Cuando trabajamos en procesos con el API de Velneo para JavaScript, sí que debemos tener en cuenta y programar la gestión de transacciones, lo que incluye también la programación del entretenedor (función clientEntertainer de la clase VRoot). Debemos asegurarnos de que sea ejecutado cada cierto número de minutos, un número en un rango mayor de 1 y menor de 10, para que el servidor realice la comprobación del que el cliente se encuentra activo, sin sobrepasar los 10 minutos de tiempo de espera.
Los manejadores de evento se agrupan en una única transacción, es decir, los manejadores de evento no generan transacciones independientes, es decir, si desde un manejador de evento que no transacciona se ejecutan dos manejadores de evento que sí lo hacen, todo quedará englobado en una misma transacción.
En las operaciones en tablas en memoria con rejillas o formularios no se genera transacción por lo que, en caso de desconexiones temporales mientras usamos una aplicación, podremos seguir trabajando en tablas en memoria.
En 3º y 4º plano, las tablas en memoria continúan generando transacción y teniéndose en cuenta a la hora de deshacer transacciones.
En caso de generar transacción en tablas en memoria en 3º plano, lo veremos reflejado en el log de transacciones.
Cuando trabajamos con procesos en los que se modifican registros tanto de tablas en memoria como en disco:
- En el caso de tablas en memoria en 1º plano únicamente, no genera transacción, y en el caso de que en el mismo proceso se generen operaciones en tablas en disco, únicamente éstas serán tenidas en cuenta en la transacción.
- En el caso de tablas en memoria en 3º plano, que se genera transacción, se tendrán en cuenta cuando en el mismo proceso se generen operaciones en tablas en disco.
En los procesos JavaScript con tablas en memoria es necesario iniciar y gestionar transacción igualmente, como si de una tabla en disco se tratase.
Última actualización 1yr ago