Problème avec Trigger vs rollback

[fl0w1983]

Bonjour,

J'utilise DB2 sous un système i5 IBM (AS/400). Ma DB fonctionne en read uncommited (dirty read). Voici ma situation :

J'ai une table (A) qui peut être mise à jour de plusieurs endroits. J'ai un trigger after update sur certains champs de la table A. Dans ce trigger, je fais appel à une procédure stockée via un process data queue. Ceci a pour effet de rouler la procédure dans un autre processus en batch afin de ne pas affecter la performance de mon application. Par contre, étant donné que cette opération se fait dans un autre travail, elle n'est pas exécutée dans le même cycle de validation.

Voici donc mon problème :

1. Un update est effectuée sur la table A.
2. Le trigger est déclenché et fait appel à la procédure B via le process data queue.
3. Un rollback est effectuée sur l'update.

Le traitement effectuée par la procédure B n'est pas rollbacké puisqu'il n'est pas dans la même transaction que l'update.

Est-ce que quelqu'un a une idée ?

Merci

[punkoff]

bonjour,

Pourquoi garder ce système ?
La gestion des transactions vous permet de gérer efficacement l'intégrité des données.

Là vous allez tenter d’émuler ceci sans garantie de résultat.
que faites vous quand la proc stock plante par exemple ?
La table A ne sera jamais rollbackée.

[fl0w1983]

Allo,

En fait, nous avons ce processus pour séparer les opérations faites sur la table A avec la procédure stockée qui met à jour un autre table et ce, afin de ne pas affecter la performance pour l'utilisateur. Si la procédure stockée prends 10 secondes à rouler, l'usager n'a pas a attendre ce 10 secs avant que sa mise à jour soit effectuée.

Le processus dans lequel roule la procédure stockée est également fait sous commitment control. S'il plante, il rollback sans venir affecter l'update sur la table A et c'Est ce qu'on veut.

[punkoff]

Bien,

Vu le système la seule chose que je vois comme ca est de checker l'existance de votre ligne dans la table A sous sa forme updaté (donc de passer la ligne entiere en parametre)

S'il ne la trouve pas => pas d'execution.

Maintenant .. si votre traitement sur la table B met du temps à ce lancer il sera possible que 2 updates sur la même lignes de la table A se fassent avant que le 1er traitement sur B n'ai le temps de checker ceci => est-ce acceptable ?

[fl0w1983]

Ok je vais regarder ce qui peut être fait en ce sens.

Merci

[punkoff]

Attendez le début de semaine prochaine avant de foncer tête baissée certain membre auront peut être d'autres idées !

[K2R400]

De toutes les manières la portée d'une transaction est limité à l'intérieur d'un même job (ou sur de multiples systèmes), donc j'aurai tendance à rejoindre les préco de punkoff.
- Perso je modifierai TABLEA pour lui rajouter un timestamp de modification. En V6R1 ce timestamp est mis à jour automatiquement s'il a été créé avec "FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP".
- Je mettrai la procédure stockée sous niveau d'isolation *CS pour éviter une lecture sale.
- Ainsi, la procédure stockée est déclenchée par la DTAQ et recoit à l'intérieur de ce dernier l'enregistrement mis à jour (le rrn ou les clés) ainsi que le timestamp et le contenu de la zone modifiée (ou des zones modifiées).
La procédure lit TABLEA à partir de la clé ou du RRN. Il y aura une attente si l'enregistrement n'a pas été committé (grâce au niveau d'isolation CS).
Dès la lecture faite, comparer les timestamp.
1) Si le timestamp lu est inférieur à celui reçu, alors il y a eu un rollback donc RAF.
2) Si le timestamp lu est égal, alors tout va bien, on traite avec les valeurs recues dans la DTAQ (contenu de(s) zone(s) modifiée(s))
3) Si le timestamp lu est supérieur (cas qu'évoquait punkoff de la double mise à jour) alors on traite aussi avec les valeurs reçues dans la DTAQ (contenu de(s) zone(s) modifiée(s)) mais avec un trigger sur TABLEA je ne vois pas comment le 3) sera possible, normalement ca devrait jamais arriver.

[pdz74]

Une proposition qui ne coute rien : si les traitements réalisés par la procédure stockée peuvent être décalés dans le temps (pas de temps réel obligatoire), le trigger peut se contenter de stocker dans une table évènementielle : dans ce cas, tout se fait dans la même UR, donc pas de désynchronisation possible. Ensuite tu développes un petit traitement batch qui reprend la table évenementielle et réalise ce que la procédure stockée devait faire.