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.
Control de reconstrucción de tablas incompleta
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.
Control de regeneración de índices completo
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.
Gestión de bloqueos
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.
Nota sobre transacciones y rollback
Si desde un proceso que no transacciona ejecutamos tres procesos que transaccionan: Procso1 Proceso2 Proceso3 Y en el proceso 2 deshacemos transacción:
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.
Transacciones desatendidas
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.
El entretenedor
Se encarga de mantener la ejecución de procesos enviados al servidor (tercer plano), manteniendo la conexión durante la ejecución del proceso.
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.).
Manejadores de evento y transacciones
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.
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.
Última actualización
¿Te fue útil?