Accès concurrent / lock [Résolu]

[stof]

Bonjour,

J'ai une procédure qui est appelée plusieurs fois pour importer plusieurs lignes d'un fichier.

Elle fait juste un insert dans une table qui a un identifiant qui s'incrémente (séquence) et des champs qui ont de foreign keys vers d'autres tables.

Ce qui se passe : une première insertion doit poser un lock sur la table et quand on appelle la procédure par la suite, ça ne répond plus.

A part faire un commit à chaque fois (ce qui n'est pas ce qu'on veut faire), comment peut-on résoudre ce problème?

[punkoff]

Bonjour,

Est-ce la même transaction qui gère votre insert et votre appel de procédure ?

Pourquoi ne voulez-vous pas faire un commit après votre insert ?

[mnitu]

C’est très vague comme explication. Avez-vous un exemple ? Sinon le type lock qui est posé sur la table en insertion ne confirme pas votre hypothèse.

[stof]

Envoyé par punkoff

Bonjour,

Est-ce la même transaction qui gère votre insert et votre appel de procédure ?

Pourquoi ne voulez-vous pas faire un commit après votre insert ?

La personne qui s'occupe de Tibco (pour ceux qui connaissent, c'est le logiciel qui parcourt le fichier et qui appelle à chaque ligne la procédure d'import) me dit que c'est bien la même transaction (c'est justement ce qui nous perturbe sur le problème).
On ne fait pas de commit car c'est tout ou rien : on ne veut pas importer qu'une partie du fichier avant d'éventuellement tomber sur une erreur.

[stof]

Peut-on faire un commit que sur une opération particulière (et non pas sur toutes les modifs en cours)?

[mnitu]

Oui, dans une transaction autonome.

[pachot]

Bonjour,
Il faudrait comprendre quel type de verrou bloque.
La réponse est dans V$LOCKED_OBJECT, et dans V$SESSION
En soi, ce que tu décris ne doit pas poser de verrou bloquant.
Est-ce qu'il y a des contraintes d'unicité autres que la PK sur la sequence ? est-ce qu'il y a des triggers ? Est-ce qu'une seule transaction fait les inserts, ou y a-t-il plusieurs sessions en parallèle ?
Cordialement,
Franck

[stof]

On a trouvé : il y avait un select beaucoup trop long dans la façon de l'écrire et qui monopolisait plusieurs tables et peut-être que ça se croisait avec une insertion... bref, en écrivant le select autrement, le problème a disparu...

[mnitu]

Envoyé par stof

On a trouvé : il y avait un select beaucoup trop long dans la façon de l'écrire et qui monopolisait plusieurs tables et peut-être que ça se croisait avec une insertion... bref, en écrivant le select autrement, le problème a disparu...

C’est très bien. Comme on vous l’a dit au départ ce n’était pas un problème de lock à l’insertion.