|
FORUMS PROFESSIONNELS WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
Fonctionnement des transactions sur HF |
Débuté par sylvain.fernandes, 14 déc. 2005 10:48 - 9 réponses |
| |
| | | |
|
| |
Posté le 14 décembre 2005 - 10:48 |
Voici une question générale sur le fonctionnement des transaction sous windev :
Le fonctionnement classique sur les SGBD traditionnels est que tant que le commit n'a pas eu lieu rien n'est ecrit en base de donnée, les autres utilisateurs ne voient donc pas ces enregistrements ce qui parait normal.
En HF par contre si des enregistrement sont crées par une transaction et que cette transaction n'est pas validée les enregistrement sont qu'en même dans la table HF et un fichier TRS est créé.
Voilà donc un cas concret qui pose probleme Un fichier fourniseur , un fichier produit chaque produit a obligatoirement un fournisseur
utilisateur 1 :Creation d'un fournisseur avec une transaction qui englobe d'autre traitement qui peuvent etre long. Utilisateur 2 :acces à la fiche fournisseur il voit bien le fournisseur malgré le fait qu'il soit en cours de transaction, il lui assoicie un produit Utilisateur 1 : annule sa transaction, le fournisseur soumis a transaction tente d'etre supprimé mais cela leve une contrainte HF sur la liaison Fournisseur client puisque un produit a obligatoirement un fournisseur.
J'ai de gros doutes sur le fonctionnement des transactions le principe même des fichiers TRS avec flag dans les tables d'enregistrement non validés par la transactions, les utilitaires qui vont avec, enfin tout cela ne me rassure pas ??? |
| |
| |
| | | |
|
| | |
| |
Posté le 14 décembre 2005 - 12:08 |
Hello, Est-ce que vous travaillez en HF ISAM ? |
| |
| |
| | | |
|
| | |
| |
Posté le 14 décembre 2005 - 14:19 |
Salut,
Hyper File utilise un mode de transaction « READ UNCOMMITED ».
Ce mode permet d'utiliser le mécanisme des transactions pour rendre atomique une opération portant sur plusieurs enregistrements d'un ou de plusieurs fichiers. Il empêche la modification des dits enregistrements sans pour autant empêcher leur consultation. Il permet également l'annulation d'une opération à tous moments.
Ce mécanisme fonctionne parfaitement en multi-utilisateur.
C'est ce qu'on demande à une transaction dans 99% des cas.
-- Ed en Ligne
"syfe" <sylvain.fernandes@ics-sud.com> a écrit dans le message de news: 439fe3ca@news.pcsoft.fr...
Voici une question générale sur le fonctionnement des transaction sous windev :
Le fonctionnement classique sur les SGBD traditionnels est que tant que le commit n'a pas eu lieu rien n'est ecrit en base de donnée, les autres utilisateurs ne voient donc pas ces enregistrements ce qui parait normal.
En HF par contre si des enregistrement sont crées par une transaction et que cette transaction n'est pas validée les enregistrement sont qu'en même dans la table HF et un fichier TRS est créé.
Voilà donc un cas concret qui pose probleme Un fichier fourniseur , un fichier produit chaque produit a obligatoirement un fournisseur
utilisateur 1 :Creation d'un fournisseur avec une transaction qui englobe d'autre traitement qui peuvent etre long. Utilisateur 2 :acces à la fiche fournisseur il voit bien le fournisseur malgré le fait qu'il soit en cours de transaction, il lui assoicie un produit Utilisateur 1 : annule sa transaction, le fournisseur soumis a transaction tente d'etre supprimé mais cela leve une contrainte HF sur la liaison Fournisseur client puisque un produit a obligatoirement un fournisseur.
J'ai de gros doutes sur le fonctionnement des transactions le principe même des fichiers TRS avec flag dans les tables d'enregistrement non validés par la transactions, les utilitaires qui vont avec, enfin tout cela ne me rassure pas ???
|
| |
| |
| | | |
|
| | |
| |
Posté le 14 décembre 2005 - 14:38 |
"Le fonctionnement classique sur les SGBD traditionnels est que tant que le commit n'a pas eu lieu rien n'est ecrit en base de donnée, les autres utilisateurs ne voient donc pas ces enregistrements ce qui parait normal." Celà dépend du niveau d'isolation utilisé par la base de données ( read uncommited, read commited, repeatable read, serializable ). Il semble donc que HF utilise le premier niveau d'isolation.
Frédéric. |
| |
| |
| | | |
|
| | |
| |
Posté le 14 décembre 2005 - 14:47 |
Il n'y a aucun doute à avoir, je confirme le fonctionnement tel que décrit ! Ensuite sur les différentes méthodes possibles, si vous en souhaites une qui n'est pas encore supportée par HF, je pense qu'une suyggestion au support s'impose ! J'utilise les transactions, et je ne rencontre pas de pbm particulier. |
| |
| |
| | | |
|
| | |
| |
Posté le 14 décembre 2005 - 14:50 |
Pour compléter ma réponse, je rajoute que je programme toujours des transactions les plus courtes possible, e que j'évite les transactions "poubelle" qui peuvent durer des heures si l'utilisateur d'absente au milieu de l'écran de saisie !!! Notre règle est de transactionner des blocs d'insctructions les plus courts possibles, et tout marche bien à quelques dizaines d'utilisateurs simultanés. |
| |
| |
| | | |
|
| | |
| |
Posté le 14 décembre 2005 - 15:18 |
Oui, c'est une règle générale : ouvrir des transactions pendant une saisie c'est vraiment une erreur grave. |
| |
| |
| | | |
|
| | |
| |
Posté le 14 décembre 2005 - 15:59 |
Le niveau minimum en environnement multiutilisateur devrait être le niveau 1 qui est souvent le niveau par défaut sous PostgreSQL, SQLserver...Dans ce cas le 99% des cas est peut être réaliste mais pas en niveau 0.
Le problème c'est que plus on va vers le niveau 4, plus le moteur doit travailler et celà ralenti l'application. Mais passer d'un niveau 4 au niveau 0 il y a une marche qui est dangereuse.
A partir du moment que les lectures impropres sont permises le mode transactionnel utilisé est inadapté dans un cadre où plusieurs utilisateurs ont accès pour faire des modifs sur les tables.
Atomique et ACID ne font pas 1! # Support complet ACID (Atomicity Consistency Isolation Durability) Ceci signifie que:
* Il est possible de définir des opérations atomiques, c'est-à-dire, former par des commandes qui s'exécutent toutes au aucunes a la fois. * Uniformité, qui garantit que la base de données ne reste jamais dans un état intermédiaire lors d'une transaction (avec une partie des commandes effectuées et d'autres non). * Isolement, qui maintient séparé les transactions des différents utilisateurs jusqu'à que celles-ci soient terminées. * Durabilité, garantissant que le serveur de données garde les actualisations en attente, de telle forme qu'elle puisse être récupéré après un arrêt brutal tel que le débranchement de la machine.
"Phil" <philippe.noireau@prive.com> writes:
Pour compléter ma réponse, je rajoute que je programme toujours des transactions les plus courtes possible, e que j'évite les transactions "poubelle" qui peuvent durer des heures si l'utilisateur d'absente au milieu de l'écran de saisie !!! Notre règle est de transactionner des blocs d'insctructions les plus courts possibles, et tout marche bien à quelques dizaines d'utilisateurs simultanés.
Le problème n'est pas que la transaction soit longue où courte. Le niveau 0 ne procure aucun isolement des transactions.
De plus en général l'intéret principal d'une transaction ce n'est pas lors de traitement court, mais plutot l'inverse
-- suivre ce lien pour répondre: http://cerbermail.com/… Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 14 décembre 2005 - 23:45 |
Les transaction HF sont en mode READ UNCOMMITED.
Une solution est de bloquer en lecture les enregistrements modifiés pendant la transaction puis de les débloquer en fin de transaction (après). On a alors un fonctionnement similaire au READ COMMITED.
( Si l'appli cliente est coupé, alors les enreg sont débloqué et en transaction interrompue ( donc innacessible, la transaction est alors annulée donc on revient bien à l'état précédent la transaction ) |
| |
| |
| | | |
|
| | |
| |
Posté le 15 décembre 2005 - 10:49 |
Le read commited n'est pas qu'un blocage à la lecture de l'enregistrement mais le read commited doit lire uniquement les enregistrements qui ne sont isolés. Hors dans Windev 9-10 tous les enregistrements sont visibles ce qui implique de rajouter à chaque traitement une gestion des enregistrements bloqués afin d'éviter les messages d'avertissement. Un peu lourd... |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|