|
|
|
|
|
|
|
|
|
|
- Présentation
- Mode d'isolation READ UNCOMMITTED
- Principe
- Exemple : Cas d'une gestion de stock
- Exemple : Cas d'une modification d'un client
- Mettre en place le mode d'isolation READ UNCOMMITTED
- Mode d'isolation READ COMMITTED
- Principe
- Exemple : Cas d'une gestion de stock
- Exemple : Cas d'une modification d'un client
- Mettre en place le mode d'isolation READ COMMITTED
- Mode d'isolation REPEATABLE READ
- Principe
- Exemple : Cas d'une gestion de stock
- Exemple : Cas d'une modification d'un client
- Mettre en place le mode d'isolation REPEATABLE READ
Transactions Client/Serveur : Modes d'isolation disponibles
 Disponible uniquement avec ce type de connexion
Le moteur HFSQL propose d'isoler les transactions : les modifications effectuées dans une transaction en cours sont isolées de celles faites dans les autres transactions conduites simultanément, jusqu'à ce qu'elle soit validée. Plusieurs modes d'isolation sont disponibles : Cette page d'aide présente ces différents modes d'isolation et comment les mettre en place. Mode d'isolation READ UNCOMMITTED Principe Lorsqu'un poste démarre une transaction, les autres postes voient les données modifiées dès que la modification (ajout, modification, suppression) a été effectuée et non pas uniquement lorsque la transaction a été validée. Bien que la transaction n'ait pas été validée (COMMIT), les autres postes lisent les nouvelles données. Si entre temps, la transaction a été annulée (ROLLBACK), les données lues par les postes sont erronées. Exemple : Cas d'une gestion de stock Considérons un fichier PRODUIT avec un article Art01 dont la quantité en stock est de 10. - Le poste A ouvre une transaction (fonction HTransactionDébut ou fonction HTransaction). Le poste A modifie l'article Art01 et retranche 2 à la quantité (fonction HModifie). La quantité en stock passe à 8 mais la transaction n'est pas validée.
- Le poste B utilise le mode d'isolation de transaction READ UNCOMMITTED et lit l'article Art01. La quantité en stock vaut 8 : la transaction du poste A n'a pas été validée et pourtant le poste B voit la quantité en stock comme si elle avait été validée.
- Le poste A a deux solutions :
- Valider la transaction (COMMIT). Dans ce cas, la quantité en stock reste à 8.
- Annuler la transaction (ROLLBACK). Dans ce cas, la quantité en stock repasse à 10.
- Durant le temps où la transaction n'était pas validée ou annulée, le poste B a vu 8 dans le stock, ce qui est faux si la transaction est annulée.
Exemple : Cas d'une modification d'un client - Un poste A modifie un enregistrement dans une transaction. Dans cette transaction, "Anne" devient "Juliette". La transaction n'est pas validée.
- Un poste B lit le même enregistrement en mode READ UNCOMMITTED. Il lit directement "Juliette".
Mettre en place le mode d'isolation READ UNCOMMITTED Pour mettre en place le mode d'isolation READ UNCOMMITTED, il faut : Mode d'isolation READ COMMITTED Principe Dans ce mode, tant que la transaction n'a pas été validée (COMMIT), les postes lisent TOUJOURS les données originales, c'est-à -dire avant les modifications effectuées durant la transaction (ajout, modification, suppression). Les modifications effectuées durant la transaction ne seront visibles qu'une fois la transaction validée (COMMIT). Exemple : Cas d'une gestion de stock Considérons un fichier PRODUIT avec un article Art01 dont la quantité en stock est de 10. - Le poste A ouvre une transaction (fonction HTransactionDébut ou fonction HTransaction). Le poste A modifie l'article Art01 et retranche 2 à la quantité (fonction HModifie). La quantité en stock passe à 8 mais la transaction n'est pas validée.
- Le poste B utilise le mode d'isolation READ COMMITTED et lit l'article Art01. La quantité en stock visualisée vaut 10.
- Le poste A a deux solutions :
- Valider la transaction (COMMIT). Dans ce cas, la quantité en stock passe à 8.
- Annuler la transaction (ROLLBACK). Dans ce cas, la quantité en stock reste à 10.
- Durant le temps où la transaction n'était pas validée ou annulée, le poste B a vu 10 dans le stock, comme si personne n'avait modifié la quantité en stock.
Exemple : Cas d'une modification d'un client - Un poste A modifie un enregistrement dans une transaction. Dans cette transaction "Anne" devient "Juliette". La transaction n'est pas validée.
- Un poste B lit le même enregistrement en mode READ COMMITTED. Il lit "Anne".
Mettre en place le mode d'isolation READ COMMITTED Pour mettre en place le mode d'isolation READ COMMITTED, il faut : Mode d'isolation REPEATABLE READ Principe Ce mode répond à des besoins particuliers. Dans ce mode, si le poste qui a démarré la transaction lit de nouveau la base de données, il lira les données dans l'état où elles étaient au démarrage de la transaction, même si d'autres postes ont validé des transactions qui modifient ces données. Durant toute la durée de la transaction, un même poste lit une "photographie" ou une "image" de la base de données qui a été prise au démarrage de la transaction, et non pas les données validées par les autres postes. Exemple : Cas d'une gestion de stock Considérons un fichier PRODUIT avec un article Art01 dont la quantité en stock est de 10. - Les postes A et B utilisent le mode d'isolation de transaction REPEATABLE READ.
- Le poste A ouvre une transaction (fonction HTransactionDébut ou fonction HTransaction). Il lit l'article Art01 et la quantité vaut 10.
- Le poste B ouvre une transaction (fonction HTransactionDébut ou fonction HTransaction). Il modifie l'article Art01 et retranche 2 à la quantité (fonction HModifie). Il valide sa transaction. Le stock passe à 8.
- Lors de la validation de la transaction (COMMIT) par le poste B, le poste A lit toujours l'article Art01 avec une quantité qui vaut 10.
- Si le poste A valide sa transaction, lors de la prochaine lecture, la quantité en stock correspondra à 8. En effet, ce n'est que quand le poste A aura validé sa transaction qu'il verra la nouvelle valeur de la quantité en stock.
Exemple : Cas d'une modification d'un client - Deux postes A et B débutent une transaction.
- Dans la transaction du poste A, "Anne" devient "Juliette". La transaction est validée
- Le poste B lit le même enregistrement. Tant qu'il n'a pas validé sa propre transaction, il lira encore "Anne".
Mettre en place le mode d'isolation REPEATABLE READ Pour mettre en place le mode d'isolation REPEATABLE READ, il faut : - Utiliser des fichiers HFSQL en mode Client/Serveur.
- Utiliser un serveur HFSQL en version 19 minimum.
- Activer le mode REPEATABLE READ dans chaque fichier de l'analyse en transaction. Cette option est disponible dans l'onglet "Détail" de la fenêtre de description du fichier. Une modification automatique des fichiers de données est nécessaire pour prendre en compte ce paramètre. Attention : si cette option est activée, le fichier est incompatible avec les versions 18 et antérieures.
- Utiliser la fonction HTransactionIsolation avec la constante hRepeatableRead.
- Dans les fonctions de gestion des transactions (HTransactionDébut, HTransaction, HTransactionFin, HTransactionAnnule), utiliser les syntaxes manipulant une connexion.
Astuce : Pour savoir si le mode REPEATABLE READ est activé sur un fichier de données, utilisez la propriété RepeatableReadSupporté.
Documentation également disponible pour…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|