Une ptite question car quelquechose doit m'échapper au niveau des
transactions...
un utilisateur crée un enregistrement dans une transaction, et alors que
cette transaction n'est pas validée, il est deja visible par les autres
utilisateurs..
Un exple :
Utilisateur1 crée 1 fournisseur dans une transaction. La transaction n'est
pas validée pour une raison ou pour une autre (utilisateur reste sur la
fiche ou traitement long ou pb réseau)...
Utilisateur2 voit ce fournisseur, y accède et lui saisit des produits ou
lance un traitement sur l'ensemble des fournisseurs.
Utilisateur1 rentre de WE et annule la transaction.
-> si la contrainte d'integrité est "Interdiction de supprimer un
fournisseur possèdant des produits" une exception HF est générée lors de
l'annulation de la transaction
-> sinon le produit reste en BD avec un ID de fournisseur qui n'existe pas
Dans tous les cas, tous les traitements qui ont touché a cette table
fournisseurs pendant le WE sont foireux...
Pour l'instant j'ai bcp de mal a appréhender l'interêt -a part publicitaire-
d'un systeme de transaction qui ecrit dans la BD des enregistrements avant
la validation de la transaction et les laissant accessibles aux autres
utilisateurs.Quelquechose doit m'échapper, comment faites-vous donc pour
assurer l'integrité et la cohérence des données?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel
"Jerome Grandmougin" writes:
Bonjour a tous !
Une ptite question car quelquechose doit m'échapper au niveau des transactions... un utilisateur crée un enregistrement dans une transaction, et alors que cette transaction n'est pas validée, il est deja visible par les autres utilisateurs..
C'est que l'isolation est en niveau 0 (READ UNCOMMITED), cf http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1.5 pour plus d'explication.
Bref, le mode transactionnel dans ce cas te permet uniquement de garder la cohérence de ta base si tu es en monoutilisateur ;-) Je rigole, quoique, dans ton exemple on est dans ce cas.
Un exple : Utilisateur1 crée 1 fournisseur dans une transaction. La transaction n' est pas validée pour une raison ou pour une autre (utilisateur reste sur la fiche ou traitement long ou pb réseau)... Utilisateur2 voit ce fournisseur, y accède et lui saisit des produits ou lance un traitement sur l'ensemble des fournisseurs. Utilisateur1 rentre de WE et annule la transaction.
-> si la contrainte d'integrité est "Interdiction de supprimer un fournisseur possèdant des produits" une exception HF est générée lors de l'annulation de la transaction -> sinon le produit reste en BD avec un ID de fournisseur qui n'existe pas
Dans tous les cas, tous les traitements qui ont touché a cette table fournisseurs pendant le WE sont foireux... Pour l'instant j'ai bcp de mal a appréhender l'interêt -a part public itaire- d'un systeme de transaction qui ecrit dans la BD des enregistrements avant la validation de la transaction et les laissant accessibles aux autres utilisateurs.Quelquechose doit m'échapper, comment faites-vous donc pour assurer l'integrité et la cohérence des données?
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Une ptite question car quelquechose doit m'échapper au niveau des
transactions...
un utilisateur crée un enregistrement dans une transaction, et alors que
cette transaction n'est pas validée, il est deja visible par les autres
utilisateurs..
C'est que l'isolation est en niveau 0 (READ UNCOMMITED), cf
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1.5
pour plus d'explication.
Bref, le mode transactionnel dans ce cas te permet uniquement de
garder la cohérence de ta base si tu es en monoutilisateur ;-)
Je rigole, quoique, dans ton exemple on est dans ce cas.
Un exple :
Utilisateur1 crée 1 fournisseur dans une transaction. La transaction n' est
pas validée pour une raison ou pour une autre (utilisateur reste sur la
fiche ou traitement long ou pb réseau)...
Utilisateur2 voit ce fournisseur, y accède et lui saisit des produits ou
lance un traitement sur l'ensemble des fournisseurs.
Utilisateur1 rentre de WE et annule la transaction.
-> si la contrainte d'integrité est "Interdiction de supprimer un
fournisseur possèdant des produits" une exception HF est générée lors de
l'annulation de la transaction
-> sinon le produit reste en BD avec un ID de fournisseur qui n'existe pas
Dans tous les cas, tous les traitements qui ont touché a cette table
fournisseurs pendant le WE sont foireux...
Pour l'instant j'ai bcp de mal a appréhender l'interêt -a part public itaire-
d'un systeme de transaction qui ecrit dans la BD des enregistrements avant
la validation de la transaction et les laissant accessibles aux autres
utilisateurs.Quelquechose doit m'échapper, comment faites-vous donc pour
assurer l'integrité et la cohérence des données?
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Une ptite question car quelquechose doit m'échapper au niveau des transactions... un utilisateur crée un enregistrement dans une transaction, et alors que cette transaction n'est pas validée, il est deja visible par les autres utilisateurs..
C'est que l'isolation est en niveau 0 (READ UNCOMMITED), cf http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1.5 pour plus d'explication.
Bref, le mode transactionnel dans ce cas te permet uniquement de garder la cohérence de ta base si tu es en monoutilisateur ;-) Je rigole, quoique, dans ton exemple on est dans ce cas.
Un exple : Utilisateur1 crée 1 fournisseur dans une transaction. La transaction n' est pas validée pour une raison ou pour une autre (utilisateur reste sur la fiche ou traitement long ou pb réseau)... Utilisateur2 voit ce fournisseur, y accède et lui saisit des produits ou lance un traitement sur l'ensemble des fournisseurs. Utilisateur1 rentre de WE et annule la transaction.
-> si la contrainte d'integrité est "Interdiction de supprimer un fournisseur possèdant des produits" une exception HF est générée lors de l'annulation de la transaction -> sinon le produit reste en BD avec un ID de fournisseur qui n'existe pas
Dans tous les cas, tous les traitements qui ont touché a cette table fournisseurs pendant le WE sont foireux... Pour l'instant j'ai bcp de mal a appréhender l'interêt -a part public itaire- d'un systeme de transaction qui ecrit dans la BD des enregistrements avant la validation de la transaction et les laissant accessibles aux autres utilisateurs.Quelquechose doit m'échapper, comment faites-vous donc pour assurer l'integrité et la cohérence des données?
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Bernardo
Daniel a exprimé avec précision :
C'est que l'isolation est en niveau 0 (READ UNCOMMITED)
Peut etre faudrait-il suggérer à Windev de rendre paramétrable le mode de gestion des transactions. Moi en tout cas c'est le mode actuel que je veux absolument conserver. En effet, il faut que les données soient immédiatement visibles.
A+
Daniel a exprimé avec précision :
C'est que l'isolation est en niveau 0 (READ UNCOMMITED)
Peut etre faudrait-il suggérer à Windev de rendre paramétrable le mode
de gestion des transactions. Moi en tout cas c'est le mode actuel que
je veux absolument conserver. En effet, il faut que les données soient
immédiatement visibles.
C'est que l'isolation est en niveau 0 (READ UNCOMMITED)
Peut etre faudrait-il suggérer à Windev de rendre paramétrable le mode de gestion des transactions. Moi en tout cas c'est le mode actuel que je veux absolument conserver. En effet, il faut que les données soient immédiatement visibles.
A+
Daniel
Bernardo writes:
Daniel a exprimé avec précision : > C'est que l'isolation est en niveau 0 (READ UNCOMMITED)
Peut etre faudrait-il suggérer à Windev de rendre paramétrable le m ode de gestion des transactions. Moi en tout cas c'est le mode actuel que je veux absolument conserver. En effet, il faut que les données soient immédiatement visibles.
A+
Il y a la fonction pèrenoel dans WD10 ;-)
cf réponse de ted-enligne sur le site de PCSOFT : ==================== Hyper File utilise un mode de transaction « READ UNCOMMITED ». Ce mode permet d'utiliser le mécanisme des transactions pour rendre atomi que 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'u ne opération à tous moments. Ce mécanisme fonctionne parfaitement en multi-utilisateur. C'est ce qu'on demande à une transaction dans 99% des cas. ======================
Le niveau minimum en environnement multiutilisateur devrait être le nivea u 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 si gnifie 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.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Bernardo <no@spam.com> writes:
Daniel a exprimé avec précision : > C'est que l'isolation est en
niveau 0 (READ UNCOMMITED)
Peut etre faudrait-il suggérer à Windev de rendre paramétrable le m ode
de gestion des transactions. Moi en tout cas c'est le mode actuel que
je veux absolument conserver. En effet, il faut que les données soient
immédiatement visibles.
A+
Il y a la fonction pèrenoel dans WD10 ;-)
cf réponse de ted-enligne sur le site de PCSOFT :
====================
Hyper File utilise un mode de transaction « READ UNCOMMITED ».
Ce mode permet d'utiliser le mécanisme des transactions pour rendre atomi que
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'u ne
opération à tous moments.
Ce mécanisme fonctionne parfaitement en multi-utilisateur.
C'est ce qu'on demande à une transaction dans 99% des cas.
======================
Le niveau minimum en environnement multiutilisateur devrait être le nivea u 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 si gnifie 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.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Daniel a exprimé avec précision : > C'est que l'isolation est en niveau 0 (READ UNCOMMITED)
Peut etre faudrait-il suggérer à Windev de rendre paramétrable le m ode de gestion des transactions. Moi en tout cas c'est le mode actuel que je veux absolument conserver. En effet, il faut que les données soient immédiatement visibles.
A+
Il y a la fonction pèrenoel dans WD10 ;-)
cf réponse de ted-enligne sur le site de PCSOFT : ==================== Hyper File utilise un mode de transaction « READ UNCOMMITED ». Ce mode permet d'utiliser le mécanisme des transactions pour rendre atomi que 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'u ne opération à tous moments. Ce mécanisme fonctionne parfaitement en multi-utilisateur. C'est ce qu'on demande à une transaction dans 99% des cas. ======================
Le niveau minimum en environnement multiutilisateur devrait être le nivea u 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 si gnifie 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.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
sse
bjr,
le moteur ne gère-t-il pas les autres niveaux de transaction ?
sse
bjr,
le moteur ne gère-t-il pas les autres niveaux de transaction ?
Antoine
<elecoest@netcourrier.com> a écrit dans le message de news:
1134571708.925622.119750@g49g2000cwa.googlegroups.com...
au vu des réponses j'ai bien peur que nous.
