Transactions (code)

De Wiki1000
(Différences entre les versions)
(Nouvelle page : ===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 » : *A...)
 
(Services de contrôle des transactions)
Ligne 62 : Ligne 62 :
 
La gestion des transactions se fait à travers des services spécifiques offerts par le [[ClassManager (code)|ClassManager]].
 
La gestion des transactions se fait à travers des services spécifiques offerts par le [[ClassManager (code)|ClassManager]].
  
====BeginTran et BeginLongTran====
+
Voir [[Gestion des transactions (CM)|Gestion des transactions]] pour les fonctions du ClassManager permettant de gérer les transactions.
Syntaxe :
+
<source lang='delphi'>procedure BeginTran;</source>
+
 
+
Exemple
+
<source lang='delphi'>
+
begin
+
  // démarre une transaction
+
  ClassManager.BeginTran;
+
end;
+
 
+
Cette opération démarre une transaction objet courte. Une transaction de base de données n’est pas déclenchée.
+
BeginLongTran démarre une transaction longue.
+
 
+
{{warning|Une instruction BeginTran doit absolument être suivie par une instruction Commit ou une instruction Rollback selon le cas.}}
+
 
+
====Commit et CommitLongTran====
+
Syntaxe :
+
<source lang='delphi'>procedure Commit;</source>
+
 
+
Exemple
+
<source lang='delphi'>
+
ClassManager.Commit;
+
</source>
+
 
+
Cette opération marque la fin d'une transaction objet. Les objets en transaction sont validés, les règles métier sont exécutées et, en cas de succès les ordres SQL de mise à jour de base de données sont envoyés.
+
 
+
En cas d'échec d'exécution de règle métier ou de mise à jour de base de données, cette opération déclenche une exception.
+
CommitLongTran valide une transaction longue.
+
 
+
====Rollback et RollBackLongTran====
+
Syntaxe :
+
<source lang='delphi'>procedure Rollback;</source>
+
 
+
Exemple
+
<source lang='delphi'>
+
ClassManager.Rollback;
+
</source>
+
 
+
Cette opération provoque l'annulation de la transaction de base de données et de la transaction objet. Elle doit se trouver dans la boucle de traitement des exceptions pour assurer une gestion correcte des erreurs, qu’elles soient des erreurs de base de données ou de traitement.
+
 
+
RollbackLongTran annule une transaction longue.
+
 
+
====BatchLongTran====
+
Syntaxe :
+
<source lang='delphi'>procedure batchLongTran;</source>
+
 
+
Exemple
+
<source lang='delphi'>
+
ClassManager.BatchLongTran;
+
</source>
+
 
+
Cette opération traite les objets d’une transaction longue. Les objets en transaction sont validés, les règles métier sont exécutées et, en cas de succès, les ordres SQL de mise à jour de base de données sont envoyés. Les objets sont libérés.
+
 
+
====CommitEx ,CommitLongTranEx et BatchLongTranEx====
+
Syntaxe :
+
<source lang='delphi'>Function CommitEx(iOptions :TCommitOptions) :Boolean;</source>
+
 
+
Exemple
+
<source lang='delphi'>
+
Try
+
ClassManager.BeginTran;
+
. . .
+
ClassManager.CommitEx(coNoConfirmDialog+coDontShowError);
+
Except
+
  ClassManager.Rollback;
+
End;
+
</source>
+
 
+
Ces fonctions permettent de contrôler finement le comportement en transaction.
+
 
+
Le paramètre iOptions peut être une combinaison des constantes suivantes :
+
*CoStayinTranOnError
+
:En cas d’erreur la transaction n’est pas annulée.
+
*CoDontShowEngineError
+
:Le dialogue des erreurs de base de données n’est pas affiché.
+
*CoLogEngineError
+
:Les erreurs de base de données sont enregistrées dans un fichier texte.
+
*coNoConfirmDialog,
+
:N’affiche pas le dialogue de confirmation de suppression.
+
*CoNoCumuls
+
:N’exécute pas la mise à jour des cumuls. Cette option peut être utile dans le cas d’import important de données.
+
 
+
{{warning|Si vous utilisez cette options vous devrez manuellement recalculer les cumuls en utilisant l’assistant de calcul des cumuls.}}
+
 
+
*CoNoTrace
+
:La mise à jour des traces, paramétrée dans l’administration, est désactivée.
+
*CoCatchErrors
+
:Les erreurs métiers sont interceptées et ne génèrent finalement qu’une seule exception. Cette option permet de contrôler l’ensemble des règles métiers et de ne pas s’interrompre à la première règle métier en erreur.
+
 
+
====TranCount====
+
Syntaxe :
+
<source lang='delphi'>Property tranCount :Integer ;</source>
+
 
+
Cette propriété retourne le niveau de la transaction active. Le niveau de transaction est incrémenté à chaque appel de BeginTran et décrémenté à chaque appel de Commit ou Rollback.
+
 
+
====InsertToTran====
+
Syntaxe :
+
<source lang='delphi'>Procedure insertToTran(index :Integer ; object :TdbObject) ;</source>
+
 
+
Cette opération insère explicitement un objet dans la transaction active. Il est possible de contrôler la position de l’objet dans la transaction.
+
 
+
====AllocTranContext====
+
Syntaxe :
+
<source lang='delphi'>Function AllocTranContext :Integer ;</source
+
 
+
Cette opération alloue un nouveau contexte de transaction.
+
 
+
====ActivateContext====
+
Syntaxe :
+
<source lang='delphi'>Function ActivateContext(icontext :Integer) :Integer ;</source>
+
 
+
Cette opération active un contexte de transaction et retourne le contexte précédemment actif.
+
 
+
====DeActivateContext====
+
Syntaxe :
+
<source lang='delphi'>Function DeActivateContext(icontext :Integer) :Integer ;</source>
+
 
+
Cette opération désactive un contexte de transaction et retourne le nouveau contexte actif.
+
  
 
===Block try except pour le contrôle des transactions===
 
===Block try except pour le contrôle des transactions===

Version du 19 juillet 2009 à 16:36

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