Paramètres de compatibilité – Transactions imbriquées (partie 3)

Bienvenue dans notre série sur les paramètres de compatibilité et les fonctionnalités « cachées » permettant d’améliorer les performances. Dans le premier article, nous avons examiné la commande QUERY BY FORMULA et son impact sur le comportement d’une application. Le deuxième article traitait de l’option de compatibilité« Utiliser le point et la virgule comme caractères de remplacement » pour éviter de se heurter au problème « les chiffres sont affichés sous la forme >>>>>>>>> » .

Dans ce troisième article, nous allons explorer les transactions imbriquées.

Si cette option n’est pas visible sur votre page de compatibilité (parce que vous avez créé votre structure avec 4D v11 ou plus) ou si elle est déjà activée, il n’est pas nécessaire de poursuivre la lecture. Si ce n’est pas le cas, votre application fonctionne dans un mode émulant 4D v2004. Non seulement vous passez à côté d’un grand nombre de fonctionnalités intéressantes, mais vous êtes également dans une position risquée, car ce mode n’est plus testé par 4D.

Lorsque 4D a introduit les transactions il y a 25 ans, il ne supportait qu’un seul niveau de transaction : les opérations étaient soit dans une transaction, soit pas. Cependant, 4D supporte les transactions multi-niveaux (imbriquées) depuis plus de 10 ans maintenant. Vous devriez en profiter !

Si vous n’avez jamais utilisé de transactions, je vous conseille de lire cet article de blog sur les transactions… sinon, continuez à lire !

Drapeau de compatibilité des transactions imbriquées

Alors, pourquoi cette option ? N’est-il pas préférable de toujours utiliser des transactions imbriquées ?

Oui, c’est beaucoup mieux. Cependant, votre code existant peut avoir été écrit avec seulement des transactions à un seul niveau, d’où l’option.

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…

Pourquoi ? Que pourrait-il se passer ? Content que vous posiez la question ! Supposons qu’un utilisateur final quitte une application avec des transactions à un seul niveau, qui peut encore avoir des transactions non confirmées et non validées ouvertes. Elles seront automatiquement annulées et tout ce travail pourrait être perdu !

Avant d’activer le drapeau de compatibilité des transactions imbriquées, vous devez examiner soigneusement votre code et vous assurer que tous les appels aux transactions sont équilibrés. Vérifiez qu’elles sont non seulement ouvertes, mais aussi fermées. Par exemple, une méthode appelée à l’intérieur d’une condition IF pourrait lancer une transaction, mais pourrait être difficile à trouver si le code n’est pas bien structuré et organisé.

Il y a deux façons de vérifier cela :

1. La première consiste à effectuer un audit complet du code, ce qui peut prendre beaucoup de temps. Cependant, il existe une autre option.
2. Si votre application n’utilise qu’un seul processus, cela peut être très simple. Dans l’événement On Exit, vérifiez s’il y a des transactions encore ouvertes. Si oui, signalez-le (envoyez un courriel, appelez l’administrateur, etc.) ET validez la transaction (en supposant qu’il s’agisse d’une transaction ouverte par accident).

Puisque vous aurez très probablement d’autres processus, vous devrez les identifier. Si vous avez une méthode générique que vous appelez dans n’importe quel processus lorsque vous le démarrez ou le terminez, pas de problème. Sinon, vous devrez trouver ces processus et modifier chacun d’entre eux. À la fin de chaque processus, vérifiez le fichier Transaction level.

À ce stade, ne faites rien d’autre. Avant de commencer à utiliser des transactions imbriquées, vérifiez votre code !

Suspendre les transactions

Dès que vous aurez activé les transactions imbriquées, vous remarquerez un autre avantage. Vous pouvez appuyer sur le bouton « snooze » !

Imaginons que vous êtes dans une transaction et que vous avez besoin d’augmenter un compteur stocké dans une autre table(par exemple, un numéro de facture). Tant que la transaction est ouverte, tous les enregistrements modifiés sont verrouillés afin que les autres utilisateurs ou processus ne puissent pas les modifier. Si cela peut convenir pour la facture elle-même, ce n’est pas le cas pour le compteur de numéros de facture. Dans le passé, les développeurs ont essayé de contourner ce problème en démarrant un autre processus et en créant des processus pour gérer la communication. Cela représente beaucoup de code juste pour exécuter quelque chose en dehors d’une transaction. Heureusement, il existe une meilleure solution… dès que les transactions imbriquées sont activées, vous pouvez les mettre en pause à tout moment. Cela vous permet d’incrémenter le compteur et de reprendre la transaction.

Cette fonctionnalité est tellement fantastique qu’elle fait l’objet d’un article entier dans la documentation!

Mémoire

Que vous utilisiez ou non des transactions imbriquées, vous devez savoir que les transactions augmentent la mémoire nécessaire car les données modifiées sont stockées dans un tampon temporaire. De plus, en interne, 4D construit également des index temporaires qui permettent d’exécuter des requêtes.

Par conséquent, plus vos tables sont grandes (car plus de champs sont indexés et plus d’enregistrements sont modifiés), plus la mémoire requise est importante. Si votre mémoire est insuffisante, vous verrez des fichiers temporaires créés à côté de vos fichiers .4DD (pour stocker le tampon temporaire). Ces fichiers, bien qu’ils résolvent le problème du manque de mémoire, peuvent réduire les performances de votre application.

Donc, même si les transactions sont formidables, ce n’est pas la meilleure idée de manipuler des millions d’enregistrements dans une seule transaction !