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.