Discussion :

[pdz74]

Bonjour,

Nous avons une table qui nous sert de serveur d'identifiants asignificatifs. Lorsqu'on souhaite récupérer une nouvelle valeur d'identifiants, un ss-pro TP réalise les actions suivantes :
- +1 sur l'identifiant demandé, c'est la 1ère action réalisée; de cette manière un verrou X est mis sur la ligne immédiatement, plus personne ne peut l'accéder, le paramètre ISOLATION de nos BIND étant bien sur à CS.
- lecture de la ligne qui vient d'être mise à jour pour renvoi au demandeur.
- COMMIT automatique lorsque le demandeur faire un RETURN à CICS ou un XCTL, ce qui se passe dans le 1/10ème de seconde qui suit.

Si un autre demandeur était en attente, il ne peut faire l'accès à la ligne demandée qu'après la libération du verrou, donc une fois que le +1 précédent a été validé.

Ce principe fonctionne depuis des années pour des dizaines d'identifiants avec des centaines de milliers de demandes par jour, le tablespace est bien sur en LOCKSIZE ROW, je ne l'avais pas précisé.

Et nous venons de tomber sur un cas ou 2 demandes sur le même identifiant, demandes distantes de 17 millièmes de seconde, ont rendu le même résultat. Bigre !!!!

Auriez vous connaissance d'un éventuel bug de DB2 qui pourrait générer cela. J'imagine le cas où la ligne serait mise à jour dans le bufferpool mais l'écriture disque non encore réalisée. Mais ce cas est courant et DB2 est sensé savoir parfaitement le gérer. Et plusieurs demandes dans la même seconde, c'est également un cas courant pour notre SI. Bref, je suis sec...

Merci d'avance si vous avez déjà été confronté à ce type de souci et si vous avez des explications.

Bonne journée.

[Oratorio]

il n'y a pas de bug db2 .. ce fonctionnement est normal
la solution de verrouiller vous-même l'enregistrement est incompréhensible
je n'ai pas compris pourquoi vous programmez vous-mêmes ce mécanisme alors que tout SGBD fournit le moyen de le faire

[pdz74]

J'avoue ne pas comprendre ta réponse. En quoi ce que je considère comme un bug est-il normal alors que dans 99,99999% des cas, ça marche ???

On verrouille justement pour que 2 demandes ne renvoient pas le même identifiant, c'est ce qui se passe lorsque ceux qui ont développé des processus équivalents, font d'abord la lecture de la table, puis la maj. Là,le risque est grand. Par contre, en faisant d'abord l'UPDATE, ça marche, à part 1 cas en 10 ans...

Quant à se servir des standards fournis par DB2, tel le ROWID ou le IDENTITY COLUMN, c'est certainement génial, mais ce n'est apparu que dans les années 2000, alors que des identifiants, ça fait 30 ans qu'on en a besoin. Et malheureusement, nous n'avons pas 200.000 jours de disponibles pour réécrire le SI...

[Mercure]

Perso, sur un cas semblable, je m'adresserais au point service IBM et leur exposerais la situation. Ils ont peut-être un correctif, une PTF ...

[bernard59139]

Bonjour

Il faudrait exactement savoir comment le +1 est fait.

Si, pour déterminer la valeur, il y a une requête sql et que, ensuite, le sous-pro fait +1, tu n'auras jamais la garantie absolue d'avoir unicité du compteur.

Bon week-end

[Oratorio]

Bonjour

Il faudrait exactement savoir comment le +1 est fait.

Si, pour déterminer la valeur, il y a une requête sql et que, ensuite, le sous-pro fait +1, tu n'auras jamais la garantie absolue d'avoir unicité du compteur.

Bon week-end

c'est ça

et pour verrouiller pendant la lecture, tout SGBD fournit une solution via ses mécanismes internes
ce truc ne marche pas à 100% quand c'est fait manuellement

[pdz74]

La logique est simple.

On passe en paramètre au ss-pro le nom de l'identifiant.

1ère instruction du ss-pro

UPDATE TABLE SET VALEUR = VALEUR +1 WHERE IDENT = paramètre

A partir de ce moment et quoi que puisse dire Oratorio, la ligne est bloquée avec un verrou de type X exclusif. Il n'y a rien de manuel, c'est un fait ! Et on ne parle pas de lecture, mais de maj !

2ème instruction du ss-pro

SELECT VALEUR FROM TABLE WHERE IDENT = paramètre

On sort du ss-pro avec la valeur en retour. Le programme appelant fait un point de COMMIT dans le 1/10ème de seconde qui suit comme précisé dans mon 1er message.

C'est tout et ça marche sauf 1 cas en 10 ans ???

[bernard59139]

Bonjour

Ok, ca ressemble à un bug.

Contacter IBM me semble souhaitable.
Et si contact il y a, j'aimerai savoir ce que le support à répondu.

Bon week-end

[alex.]

Hello,

C'est un bug qui ressemble à un de ceux que j'avais remonté à IBM, il y a quelques années. Réponse d'IBM pas de correctif. Workaround passer en currentdata yes. Si t'y es déjà c'est un autre cas.

http://www-01.ibm.com/support/docvie...id=swg1PK21086

[Luc Orient]

Même si ce n'est pas exactement la façon de faire que nous préconisons sur notre site dans ce cas de figure (on préconise plutôt la lecture avec intention de mise à jour (SELECT ... FOR UPDATE) puis la mise à jour (UPDATE), cette façon de faire m'apparaît correcte.

Il serait intéressant d'avoir la réponse d'IBM sur cette question, bien que mon experience me fait dire qu' il ne faut pas en attendre des miracles ...

Question annexe :
Vous êtes en SYSPLEX ou pas ?

[pdz74]

Bonjour,

Merci à tous pour vos réponses. Pour le currentdata, je vérifierai lundi. Pour le reste, oui on est en sysplex.

Dès lundi, j'ouvre un incident chez IBM, mais je suis assez d'accord avec Luc Orient pour ne pas m'attendre à grand chose...

Je vous tiens bien sur au courant.

Merci encore et bon week.

[Oratorio]

On sort du ss-pro avec la valeur en retour. Le programme appelant fait un point de COMMIT dans le 1/10ème de seconde qui suit comme précisé dans mon 1er message.

le COMMIT est fait après la lecture
entre l'UPDATE et le SELECT il peut se passer des choses
c'est une erreur de programmation
il faut commencer par un select d'abord en verrouillant l'enregistrement..

[Luc Orient]

...
entre l'UPDATE et le SELECT il peut se passer des choses
c'est une erreur de programmation
il faut commencer par un select d'abord en verrouillant l'enregistrement..

Faux.
L'exécution de l'ordre UPDATE pose un verrou exclusif de type X sur la page (ou la ligne selon l'option de verrouillage du Tablespace associé) et ce verrou est conservé jusqu'à la fin de l'unitié d'oeuvre (COMMIT ou ROLLBACK).

[Macfurp]

Bonjour,

Quant à se servir des standards fournis par DB2, tel le ROWID ou le IDENTITY COLUMN, c'est certainement génial, mais ce n'est apparu que dans les années 2000, alors que des identifiants, ça fait 30 ans qu'on en a besoin. Et malheureusement, nous n'avons pas 200.000 jours de disponibles pour réécrire le SI...

je te fais partager un expérience similaire... nous avions ( naguère / jadis / autrefois / ... ) des problèmes de timeout sur une table de numérotation également mise à jour par l'intermédiaire d'un sous-programme dans différentes transactions.

L'origine des timeouts était la très mauvaise utilisation du sous-programme dans de nombreux applicatifs : appel au fil de l'eau effectué sans commit immédiat et pouvant être suivi de nombreuses autres mises à jour ou autres traitements plus ou moins longs...

Pour éviter la modification fastidieuse de tous ces traitements, nous avons remplacée la table de numérotation par une Sequence (introduite en V8). Seul le module de numérotation a évolué, la mise en place a été quasiment neutre au niveau applicatif et il n'y a plus eu depuis de problème de verrouillage.

Il y a toutefois quelques inconvénients : une valeur de sequence attribuée est définitive aussi il peut y avoir de trous de séquence non récupérables et il est plus compliqué d'obtenir les valeurs des numéros attribués, ...

A+

[Peut-êtreUneRéponse]

Sans rentrer dans dans le débat "bien codé/pas bien codé", je rejoins Macfurp : les séquences objet sont vraiment très pratiques, empêche une gestion parfois hasardeuse de tables de numérotation et demande un minimum de modification. Je comprend toutefois que ce "minimum" puisse être trop coûteux.