Discussion :

[crischprolch]

Bonjour,

j'ai besoin de faire une insertion ou un update selon qu'un enregistrement existe ou pas. Mon ami google m'a alors proposé de faire un merge. Mon problème, c'est que cette requete peut etre executée (pour un meme enregistrement) en meme temps par 2 processus distincts. Du coup, un des 2 devrait faire une insertion puis l'autre un update.

Résultat : une requete est executée et avant qu'elle soit finie, la meme est executée (meme id qui est une primary key !!). Du coup quand une des deux se finit, un enregistrement a été créé mais quand l'autre se termine, un autre est en train d'être crée (avec donc le meme id) mais évidemment, cela ne fonctionne pas (par contre, je n'ai aucune exception pour cela!!).

Comment dois-je faire pour contourner ce problème ?

[mnitu]

Je ne pense pas que tu est assez clair dans la description du problème ; l’emploi ou pas du merge ne devrait rien changer. Peux tu détailler ?
Le fait que merge est exécuté simultanément pour le même id devrait générer une enregistrement dans une des sessions et échouer avec une violation du contrainte d’unicité dans l’autre.

[fatsora]

Quelle est la version Oracle ?


mais est ce que la 2e transaction ne fait elle pas un update (car l'insertion a ete
faite)
c'est ptet pour ca qu'il n'y a pas demessage d'erreur ?

fais voir le code ....

[crischprolch]

Suite à ta remarque sur la précision de ma description, j'ai relancé des tests. Il arrive parfois que tout fonctionne bien (cela doit être parce qu'il y a eu un petit temps mort qui a permis à une des requetes de s'executer), parfois j'ai deux insertions et parfois j'en ai une des deux qui ne produit aucun resultat (pas de violation du contrainte d’unicité).

Je me demande quel genre de verrou est posé lors d'un merge ?

Ne devrais-je pas verrouiller la table ? Si oui, comment ?

[crischprolch]

fatsora : j'ai mis du temps à répondre et je n'avais pas vu ton message...

Le problème, c'est que j'ai 3 comportements possibles et je ne m'explique pas pourquoi.

[fatsora]

essaie ca

quand il n'y a pas de violation, c'est ptet des updates ?



http://www.quest-pipelines.com/newsletter-v4/0903_D.htm

il permet de voir les lignes updates, insérés


quelle version oracle utilises-tu ?

[Waldar]

Essayez peut-être de mettre du cache au niveau de la séquence qui gère la PK.

[crischprolch]

Je rectifie ce que j'ai dit auparavant car après d'autres tests, je n'ai que 2 cas : soit j'ai un insert puis un update (bien ce que je veux), soit j'ai 2 insert (en fait, je n'ai pas d'id qui s'incrémente automatiquement, je le fais à la main avec une sequence lors d'un insert dc il ne peut y a voir de violation de contrainte d'unicité).

Le problème doit dc etre sur le niveau de lock de mes merge, non ?

PS : désolé, j'ai l'impression d'être lundi matin très tôt...^^

[skuatamad]

je le fais à la main avec une sequence lors d'un insert dc il ne peut y a voir de violation de contrainte d'unicité

Par contre tu devrais avoir une contrainte d'unicité sur tes clés candidates, la PK numérique permettant juste de simplifier la mise en relation des tables.

[crischprolch]

Par contre tu devrais avoir une contrainte d'unicité sur tes clés candidates, la PK numérique permettant juste de simplifier la mise en relation des tables.

Désolé mais je ne comprends pas ce que tu veux dire par-là...

[mnitu]

Je rectifie ce que j'ai dit auparavant car après d'autres tests, je n'ai que 2 cas : soit j'ai un insert puis un update (bien ce que je veux), soit j'ai 2 insert (en fait, je n'ai pas d'id qui s'incrémente automatiquement, je le fais à la main avec une sequence lors d'un insert dc il ne peut y a voir de violation de contrainte d'unicité).
...

Voilà les comportements à attendre pour ce type de situation (en fait le deuxième cas échoue avec violation de contraint d'unicité). Mais que veux tu obtenir en fait ?

[crischprolch]

Voilà les comportements à attendre pour ce type de situation (en fait le deuxième cas échoue avec violation de contraint d'unicité). Mais que veux tu obtenir en fait ?

En fait non, car seul le premier cas est normal (je rappelle que mes processus travaillent sur un seul enregistrement). En fait cela signifie que lorsque le processus qui se déclenche en 2° teste la clause "on" du merge, il ne prend pas en compte le résultat du premier (en tt cas, il ne voit pas l'insert du premier). D'où ma question sur un éventuel lock...

[mnitu]

En fait non, car seul le premier cas est normal (je rappelle que mes processus travaillent sur un seul enregistrement). En fait cela signifie que lorsque le processus qui se déclenche en 2° teste la clause "on" du merge, il ne prend pas en compte le résultat du premier (en tt cas, il ne voit pas l'insert du premier). D'où ma question sur un éventuel lock...

C'est exactement comme ça que les choses doivent se passer! Vous voulez dire plutôt que cella ne vous convient pas!

[crischprolch]

C'est exactement comme ça que les choses doivent se passer! Vous voulez dire plutôt que cella ne vous convient pas!

Le merge que j'ai fait a pour but de créer un enregistrement si la clause "on" n'est pas vérifiée ou de l'updater sinon. Je pense que c'est plus un problème de timing (la deuxième requête arrive trop tôt pour voir le résultat de la première). J'espère m'exprimer clairement...

[fatsora]

as tu essayé ceci



Date d'inscription: février 2006
Messages: 68

Par défaut
essaie ca

quand il n'y a pas de violation, c'est ptet des updates ?



http://www.quest-pipelines.com/newsletter-v4/0903_D.htm

il permet de voir les lignes updates, insérés


quelle version oracle utilises-tu ?

[crischprolch]

as tu essayé ceci



Date d'inscription: février 2006
Messages: 68

Par défaut
essaie ca

quand il n'y a pas de violation, c'est ptet des updates ?



http://www.quest-pipelines.com/newsletter-v4/0903_D.htm

il permet de voir les lignes updates, insérés


quelle version oracle utilises-tu ?

Non je n'ai pas pris le temps d'essayer cela...

Quant à la version d'oracle, c'est la 10 si je ne m'abuse.

[mnitu]

La table T ne contient pas l’enregistrement de ID 100.
La session A exécute le merge pour le ID 100. Comme cette enregistrement n’existe pas elle fait l’insert. A peu près dans le même temps la session B exécute le merge.

Si la session A a fait le commit alors la session B voit l’enregistrement et fait un update.
Si la session A n’a pas encore fait le commit le niveau d’isolation d’Oracle par défaut (read commited) garanti que la session B ne voit pas l’enregistrement inséré par A et donc fait un insert et bloque. Quand la session A exécute le commit la session B échoue avec violation de contrainte d’unicité. Si la session A exécute rollback la session B abouti.

Si ce comportement ne vous convient pas vous devez utiliser des verrous pour sérialiser les deux transactions.

[crischprolch]

Merci.

C'est effectivement ce qui doit se passer. Je pense que je vais utiliser des verrous pour empêcher B d'écrire tant que A n'a pas fini, en espérant que ça ne pénalise pas trop les performances.

Merci à tous pour votre aide (je ne peux pas tester cette solution pour le moment mais j'essaierai très bientôt...)