Lock table DB2 [Résolu]

[rapha51]

Bonjour,

Je suis un débutant en DB2 et je me pose des questions sur la gestion des verrous de table sur DB2 :
si une application 1 insére un enregistrement dans la table A mais ne fait pas le commit instantanément.
si une application 2 insére un enregistrement dans la table A avant que l'application 1 ait fait le commit, l'insertion ne se fait pas ?

Merci d'avance.

Raphaël

[alex.]

Bonjour,

Cela dépend. Lorsque tu fais une mise à jour, tu prends un lock sur une ressource qui en fonction du paramétrage (granularité) peut être la table, la page ou la ligne. Ce verrou ne sera libéré qu'au commit (explicite si codé, implicite si fin de la tâche ou autocommit). En général, le niveau page est un bon compromis. Donc dans ton cas et avec un verrouillage page, si tu inséres concuramment dans la même page, l'application 2 sera en attente que l'application 1 commite. Si la 1 ne commite pas et ne libére donc pas son verrou et incidemment la page, la 2 "timeoutera" au delà d'un temps prédéfini au paramétrage de ta base. Si les 2 applications insérent dans des pages différentes, pas de problème.

Alex.

[rapha51]

Merci pour ta réponse.
J'ai encore deux question :
- c'est quoi le niveau page ?
- comment changer le paramétrage 'granularité' ?

Merci d'avance et bonne journée.

Raphaël

[alex.]

Les données sont stockées logiquement dans des tables et des lignes/colonnes. Physiquement, elles sont dans des tablespaces découpés en extents/segments puis en pages et enfin les enregistrements/lignes de la tables. La granularité et le type dépend de la plateforme. Pour z/OS, elle se définit dans le create tablespace, pour LUW, dans le create table et le niveau page n'existe pas (row ou table). On peut modifier la granularité avec un alter.

Alex.

PS : sur ce forum, il faut toujours préciser la plateforme sur laquelle on travaille (LUW, zOS ou AS400).

[rapha51]

En fait je travaille sous windows.

Je viens de vérifier et ma table est en granularité 'ligne', donc si j'ai bien compris mon 2e insert ne devrait pas attendre le commit du premier insert car tous les 2 travaillent sur la même table mais pas sur la même row ?

PS : ce n'est pas le cas, je suis bloqué

Merci pour tout.

Raphaël

[Luc Orient]

Envoyé par alex.

... Donc dans ton cas et avec un verrouillage page, si tu inséres concuramment dans la même page, l'application 2 sera en attente que l'application 1 commite. Si la 1 ne commite pas et ne libére donc pas son verrou et incidemment la page, la 2 "timeoutera" au delà d'un temps prédéfini au paramétrage de ta base. Si les 2 applications insérent dans des pages différentes, pas de problème.

Moi j'aurais dit (en DB2 z/OS au moins ...) que si un processus a déjà inséré (l'instruction INSERT) dans une page donnée sans avoir encore fait un commit et qu'un second processus veut insérer dans la même table alors DB2 ne choisira pas la page verrouillée et, sans attendre que cette dernière se libère, ira insérer dans une autre page ...

[alex.]

Effectivement, merci pour cette précision. En LUW, le niveau page pour le locking n'existant pas, le problème ne se pose pas.

[rapha51]

donc c'est normal ou pas que mon 2e insert soit bloqué ?

Merci pour toutes vos réponses.

Raphaël

[alex.]

Non, ce n'est pas normal. Tu devrais passer sans problème, si tu n'inséres qu'une ligne dans chaque application. Ton appli ne fait que ça ?

Alex.

[rapha51]

Oui en fait pour mes tests :
- j'insére une ligne dans la table A depuis un éditeur SQL (Toad) et je ne fais pas de Commit
- j'insére une ligne dans la table B depuis une application PHP et là tant que je fais pas de commit sous Toad ma page reste bloquée.

Merci d'avance.

Raphaël