Discussion :

[PMAR]

Bonjour à tout le monde !

J'ai lu l'excellent article de SQLPro concernant la représentation intervallaire des listes arborescentes http://sqlpro.developpez.com/cours/arborescence/.
Je me suis d'abord intéressé à la problématique de l'accès concurrent dans le cas de l'insertion (je ne suis pas allé plus loin) et il me semble avoir trouvé une faille dans la manière de faire et je soumets à votre sagacité ma réflexion (qui, je l'espère, n'est pas foireuse car je connais plus Oracle que SQLServer !).
Dans le code la procédure SP_INS_NOMENCLATURE, il y a dès le début le commencement d'un transaction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
-- démarrage transaction 
 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 
 BEGIN TRANSACTION INSERT_NOMENCLATURE

puis il y a la récupération de la valeur du père :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
-- Le parent existe toujours ?
 SELECT @OK = count(*) FROM T_NOMENCLATURE_NMC WHERE NMC_ID = @id_parent
 IF @OK = 0 OR @OK IS NULL
 BEGIN
    RAISERROR ('Insertion impossible, le parent n''existe plus !', 16, 1)
    GOTO LBL_ERROR
    RETURN
 END
 
-- On a un parent : on récupère ses éléments
 SELECT @bgp = NMC_BG, @bdp = NMC_BD, @nivp = NMC_NIVEAU 
        FROM T_NOMENCLATURE_NMC 
        WHERE NMC_ID = @id_parent

puis enfin, il y a la mise à jour des bornes dans les différents cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
-- insertion d'un père
 IF @mode = 'P'
 BEGIN
    -- Décalage de l'ensemble colatéral droit
    UPDATE T_NOMENCLATURE_NMC
           SET NMC_BD = NMC_BD + 2
           WHERE NMC_BD > @bdp
...

Sur le principe, j'ai 2 remarques à faire :
1°) la première est que faire SELECT @OK=count(*)... pour savoir si le parent existe toujours n'est pas suffisant car l'enregistrement peut être modifié (bornes modifiées par exemple) ou supprimé entre temps quand on fait le SELECT @bgp=... suivant. Il faudrait faire un SELECT WITH HOLDLOCK (ou un SELECT FOR UPDATE en Oracle)
2°) en conséquence du 1°) les UPDATE pour modifier les bornes peuvent être faux.

Vos avis ?

[SQLpro]

1°) la première est que faire SELECT @OK=count(*)... pour savoir si le parent existe toujours n'est pas suffisant car l'enregistrement peut être modifié (bornes modifiées par exemple) ou supprimé entre temps quand on fait le SELECT @bgp=... suivant. Il faudrait faire un SELECT WITH HOLDLOCK (ou un SELECT FOR UPDATE en Oracle)

Non monsieur, il faudrait peut être comprendre ce qu'est le niveau d'isolation SERIALIZABLE (norme SQL) avant de dire des choses pareille.
Ce niveau d'isolation assure que les données seront stable pendant toute la transaction.
La seule chose qui importe est deonc la valeur de la clef que l'on veut mouvoir !
Faire un HOLDLOCK en plus est non seulement d'une grande bétise mais prouve que vous ne comprenez pas le concept de transaction et que vous ne maitrisez pas les verrous !
En l'occurence rajouter des verrous dans une transaction alors qu'on y pilote un niveau d'isolation qui fait que c'est le serveur qui décide des verrous à poser est franchement abérant et ne peut que conduire à une application pourrie !
Dans le principe on ne devrait JAMAIS utilsier directement les verrous.
En 15 ans de carrière dans l'informatique et an tant qu'expert en SQL et bases de données, je n'ai jamais eût besoin de le faire et cette technique intervallaire je l'ai expérimentée sur des volumes de données considérables en environnement à forte charge (plusieurs milliers d'utilisateur et réplication).

2°) en conséquence du 1°) les UPDATE pour modifier les bornes peuvent être faux.

N'importe quoi !

Commencez par apprendre le SQL, mettez en pratique les bons conseils et évitez de douter des choses que vous ne maitrisez pas !

A +