Transactions (code)

De Wiki1000
Version du 16 septembre 2011 à 13:37 par Syfre (discuter | contributions)
(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)

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.

Info-20px.png 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.

Info-20px.png 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 ».

Tip-20px.png Tip : Il est déconseillé de démarrer des transaction dans des règles métiers.

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étierDéveloppement DSM

Outils personnels