Ajustes de compatibilidad – Transacciones anidadas (Parte 3)

Bienvenido a nuestra serie actual sobre ajustes de compatibilidad y características «ocultas» para mejorar el rendimiento. En el primer post, vimos el comando QUERY BY FORMULA y su impacto en el comportamiento de una aplicación. El segundo post fue sobre la opción de compatibilidad«Usar punto y coma como marcadores de posición» para evitar encontrarse con el problema de «los números se muestran como >>>>>>>>>» .

En esta tercera entrega, vamos a explorar las Transacciones Anidadas.

Si esta opción no está visible en su página de compatibilidad (porque ha creado su estructura con 4D v11 o posterior) o ya está activada, no es necesario seguir leyendo. Si este no es el caso, su aplicación se está ejecutando en un modo que emula a 4D v2004. No sólo se está perdiendo un montón de grandes características, sino que también está en una posición de riesgo ya que este modo ya no está probado por 4D.

Cuando 4D introdujo por primera vez las transacciones hace 25 años, sólo soportaba un único nivel de transacción: las operaciones estaban o no en una transacción. Sin embargo, desde hace más de 10 años 4D soporta transacciones de varios niveles (anidadas). ¡Debería aprovecharlas!

Si nunca ha utilizado las transacciones, le aconsejo que lea esta entrada del blog sobre las transacciones… si no, ¡siga leyendo!

Bandera de compatibilidad con las transacciones anidadas

Entonces, ¿por qué hay una opción en absoluto? ¿No es mejor utilizar siempre las transacciones anidadas?

Sí, es mucho mejor. Sin embargo, su código existente puede haber sido escrito con transacciones de un solo nivel, de ahí la opción.

START TRANSACTION
START TRANSACTION // second call by accident, ignored from 4D v2004
VALIDATE TRANSACTION // v2004 was now at the end, no transaction running anymore
// v11 still has a transaction open…

¿Por qué? ¿Qué podría pasar? ¡Me alegro de que lo preguntes! Digamos que un usuario final sale de una aplicación con transacciones de un solo nivel, que puede tener todavía abiertas transacciones no confirmadas y no validadas. ¡Se cancelarán automáticamente y todo ese trabajo podría perderse!

Antes de habilitar el indicador de compatibilidad de transacciones anidadas, debería revisar cuidadosamente su código y asegurarse de que todas las llamadas a las transacciones están equilibradas. Verifique que no sólo están abiertas, sino también cerradas. Por ejemplo, un método llamado dentro de una condición IF podría iniciar una transacción, pero podría ser difícil de encontrar si el código no está bien estructurado y organizado.

Hay dos maneras de comprobar esto:

1. La primera es hacer una auditoría completa del código, lo que podría llevar mucho tiempo. Sin embargo, hay otra opción.
2. Si su aplicación utiliza sólo un proceso, podría ser muy sencillo. En el evento On Exit, comprueba si hay alguna transacción aún abierta. Si la respuesta es afirmativa, repórtela (envíe un correo electrónico, llame al administrador, etc.) Y valide la transacción (asumiendo que fue una transacción abierta por accidente).

Como lo más probable es que tengas más procesos, necesitarás identificarlos. Si tienes un método genérico que llamas en cualquier proceso cuando lo inicias o lo terminas, no te preocupes. Si no, tendrás que encontrar estos procesos y modificar cada uno de ellos. Al final de cada proceso, comprueba el método Transaction level.

En este punto, no haga nada más. Antes de empezar a usar transacciones anidadas, ¡revisa tu código!

suspender las transacciones

Tan pronto como haya habilitado las transacciones anidadas, notará otro beneficio. ¡Puede pulsar el botón de suspensión!

Digamos que está dentro de una transacción y necesita aumentar un contador almacenado en otra tabla(por ejemplo, un número de factura). Mientras la transacción esté abierta, todos los registros modificados estarán bloqueados para que otros usuarios o procesos no puedan modificarlos. Aunque esto puede estar bien para la factura en sí, no es tan bueno para el contador de números de factura. En el pasado, los desarrolladores trataron de solucionar este problema iniciando otro proceso y creando procesos para manejar la comunicación. Eso es un montón de código sólo para ejecutar algo fuera de una transacción. Afortunadamente, hay una forma mejor… en cuanto se habilitan las transacciones anidadas, se pueden pausar en cualquier momento. Esto le permite incrementar el contador y reanudar la transacción.

¡Esta es una característica tan fantástica que hay un artículo entero en la documentación sobre ella!

Memoria

Tanto si utiliza transacciones anidadas como si no, debe tener en cuenta que las transacciones aumentan la memoria necesaria porque los datos modificados se almacenan en un buffer temporal. No sólo eso, sino que internamente 4D también construye índices temporales que permiten la ejecución de consultas.

En consecuencia, cuanto más grandes sean sus tablas (ya que se indexan más campos y se modifican más registros), más memoria se necesitará. Si su memoria es insuficiente, verá que se crean archivos temporales junto a sus archivos .4DD (para almacenar el buffer temporal). Estos archivos, si bien resuelven la escasez de memoria, podrían disminuir el rendimiento de su aplicación.

Así que, aunque las transacciones son geniales, ¡no es la mejor idea manipular millones de registros dentro de una sola!