Transactions (code)
Sommaire |
Introduction
Une transaction est une suite d'opérations effectuées comme une seule unité logique de travail.
Une transaction doit posséder les propriétés « ACID » :
- Atomicité : une transaction doit être une unité de travail indivisible ; soit toutes les modifications de données sont effectuées, soit aucune ne l'est.
- Cohérence : lorsqu'elle est terminée, une transaction doit laisser les données dans un état cohérent.
- Isolation : chaque transaction est exécutée isolément par rapport aux autres transactions.
- Durabilité : lorsque la transaction prend fin et s’est correctement exécutée, les données sont modifiées de manière permanente dans la base de données.
Transaction objet et transaction SQL
Le framework Ligne 1000 étant un framework objet, il implémente des transactions objet. Une transaction objet délimite un ensemble d’opérations sur un ensemble d’objets. Les propriétés ACID caractéristiques d’une transaction sont garanties sur l’ensemble des objets intervenant dans la transaction.
Note : Une transaction objet n’est pas une transaction SQL. En général le démarrage d’une transaction objet ne démarre pas une transaction SQL dans la base de données. |
On distingue deux types de transaction objet :
Les transactions objets dite « courtes ».
Une transaction objet courte maintient les objets intervenant dans la transaction en mémoire pendant toute la durée de la transaction. Lors de la validation de la transaction une transaction SQL est créée pour la mise à jour de la base de données. Cette transaction SQL n’existe que pendant la phase de validation de la transaction. Ce type de transaction ne peut traiter qu’un nombre limité d’objets dépendant de la capacité mémoire de la machine.
Les transaction objets dite « longues ».
Une transaction objet « longue » démarre une transaction SQL dès le démarrage de la transaction. Les objets intervenant dans la transaction sont validés par paquet, lorsque leur nombre atteint un certain seuil, et transmis à la transaction SQL. La validation de la transaction objet termine la transaction SQL. Dans ce mode de transaction le nombre d’objets conservés en mémoire ne dépasse pas la taille d’un paquet. Ce type de transaction peut traiter un nombre non limité d’objets.
Modèle de transaction
Le modèle de transaction implémenté dans la Ligne 1000 possède les caractéristiques suivantes :
- Contrôle explicite de la transaction par les ordres BeginTran, Commit et Rollback.
- Pas de transaction imbriquée, l’imbrication de transaction incrémente un niveau de transaction (TranCount), seul un Commit au niveau le plus bas est pris en compte.
- Les transactions sont gérées à l’intérieur d’un contexte, le contexte de transaction. A un instant donnée il peut exister plusieurs contextes de transaction mais un seul est actif.
Lorsqu’un objet est modifié, il est automatiquement ajouté à la transaction active ; si aucune transaction n’est démarrée une exception est levée.
Contexte de transaction
Le framework supporte la gestion de plusieurs transactions objets simultanément, une transaction existant dans un contexte de transaction.
Un contexte de transaction peut contenir zéro ou une transaction et peut être créé soit par l’interface utilisateur soit par le code métier.
Note : Le contexte de transaction est contenu dans le contexte de session, en multi-utilisateur les contextes de transactions ne sont pas partagés entre les utilisateurs |
Interface utilisateur et transactions
L’interface utilisateur démarre automatiquement des transactions objet lorsque l’utilisateur commence des modifications.
Ces transactions sont dites « implicites » et sont contrôlées par l’interface utilisateur.
- A un écran est associé un contexte de transaction.
- Un écran modal partage le contexte de transaction de l’écran qui l’a créé.
- La focalisation d’un écran active automatiquement son contexte de transaction.
- Un écran ne peut être fermé que si la transaction qui lui est associée est vide ; si une transaction est démarrée, l’utilisateur doit soit l’annuler soit la valider.
Exemple
Modification du libellé du compte général puis clic sur le bouton : un message d’annulation de transaction implicite apparaît.
Code métier et transactions
Lorsque le développeur désire modifier des objets dans le code métier, il doit le faire dans un contexte de transaction. Pour cela il doit démarrer et contrôler explicitement la transaction.
Ces transactions soit dites « explicites ».
Services de contrôle des transactions
La gestion des transactions se fait à travers des services spécifiques offerts par le ClassManager.
Voir Gestion des transactions pour les fonctions du ClassManager permettant de gérer les transactions.
Block try except pour le contrôle des transactions
Lors d’une transaction, une erreur peut se produire avant ou pendant l’instruction Commit. Pour une gestion correcte de ces erreurs il est nécessaire d’utiliser un bloc d’instruction try…except qui encadre les instructions faisant partie de la transaction.
Exemple
begin ClassManager.BeginTran; // Début de la transaction try // Début du bloc try…except ………. ClassManager.Commit; // Envoie le contenu de la transaction au serveur SQL except ClassManager.RollBack; // Annule la transaction suite à une erreur ProgressMessage('Erreur'); raise; end; end;
Exemple d'utilisation d'une transaction longue
begin // déclenchement d'une transaction longue ClassManager.BeginLongTran(100,'TPiece'); // // début de la boucle de traitement des exceptions try vCurseurCumul := CreateCursor('TCumulPeriodeCompte'); . . . // boucle de traitement while not vCurseurCumul.Eoi do begin . . . // vérification du nombre d'objets en mémoire; lancement de la // validation et de la mise à jour si le nombre d'objets dépasse // le seuil de 100 ClassManager.BatchLongTran; // itération de la boucle de traitement vCurseurCumul.Next; end; // fin de la transaction longue, validation des objets restants et // mise à jour de la base de données ClassManager.CommitLongTran; // traitement des exceptions : exceptions du traitement et de la // base de données. except; // annulation de la transaction : objet et base de données ClassManager.RollbackLongTran; // rédéclanchement de l'exception raise; end; end;
— Code métier — Développement DSM —