Discussion :

[Barbibulle]

Réponse Normande : "Ça dépend"...

Mon avis : Il n'y a pas vraiment de durée seuil qui sépare une transaction longue d'une courte... Cette durée est variable en fonction du taux de sollicitation de votre base de données.

Une base de données qui n'est attaquée que par 2 clients au rythme de 2 à 4 mise à jours par jours va supporter très facilement des transactions de durée conséquentes.
Contrairement à une base de données plus sollicité par des centaines de clients et centaines de mises à jours par heures.

Tout est relatif donc.

Mais pour ma part je considère une transaction courte comme étant une transaction dans lequel je ne fais qu'un traitement qui ne s'arrête pas, qui n' a pas besoin d'intervention humaine avant de se fermer.
Une transaction longue c'est par exemple l'affichage d'une grille. Si on n'utilise pas de cache, la transaction reste ouverte le temps que l'utilisateur ferme l'écran de la grille... Autant dire qu'une tel transaction peut rester ouverte très longtemps, les humains ayant la fâcheuse habitude de laisser les applications ouverte, partent prendre un café, ou autre

[edam]

je ne pense que du bien, mais perso je ne l'utilise pas

tu peut dire ta méthode? merci
pour moi, j'ai eu des problème avec snapshot c'est pourquoi je passe à read_commit,surtout pour le modification la gestion de stock (changement de quantité d'article par tt les utilisateurs)
je sais pas la différence entre readcommit et snapshot avec commit, car la on lit ou écrire dans une transaction fermer immédiatement

[Barbibulle]

La snapshot est à éviter autant que possible.
C'est la transaction qui est utilisée pour les backups.

Il faut s'imaginer que c'est une photo instantanée de toute la base de données. Autant vous dire que sur une base de données où il y a pas mal de mise à jours cela donne pas mal de travail à firebird. (Obligation de conserver les versions des enregistrements avant qu'ils ne soient modifiées par les autres transactions).

Pour ma part dans toutes les applications que j'ai pu créer, je n'ai pas eut le besoin d'utiliser une snapshot.

[edam]

La snapshot est à éviter autant que possible.
C'est la transaction qui est utilisée pour les backups.
....
Pour ma part dans toutes les applications que j'ai pu créer, je n'ai pas eut le besoin d'utiliser une snapshot.

normalement c'est le mode par défaut des transaction sous delphi (ib et fb);
je crois que avec commit rapide pas de problème de type de transaction, mais avec CommitRetaining mieux utilisé read_commit, et lecture seul pour lire les dernière modification sur la base, c'est sa??
citation

Le niveau d’isolement SNAPSHOT est intéressant à décrire : Lorsqu’on commence une transaction SNAPSHOT on conserve l’heure du démarrage DebT1 et toutes les lectures qui seront exécutées depuis cette transaction se réfèreront aux états stables des enregistrements antérieurs à DebT1. Cette transaction n’est donc jamais bloquée en lecture et ne peut jamais recevoir de données inconsistantes. Au moment où T1 veut exécuter un COMMIT elle reçoit une heure de COMMIT ComT1 supérieure à toutes les autres DebT et ComT d’autres transactions qui auraient pu démarrer après elle. Le COMMIT de T1 ne sera validé que si aucune autre transaction validée entre DebT1 et ComT1 n’a écrit de données que T1 aurait pu aussi écrire. Cette fonctionnalité est appelée “Le premier qui valide gagne” (First-committer-wins) et permet d’éviter les anomalies P4 et P4C. Au moment où T1 est validée les modifications qu’elle a apportées aux données ne seront visibles qu’aux transactions qui auront démarré après ComT1.

là, je reviens à cette discutions avec snapshot pas de problème si deux transaction sont ouvert au même temps le premier qui valide passe et l'autre aura un exception; mais avec read_commit sa passe et on est obligé après de testé si les nbr des places n'est pas inférieur à 0, et si par malheur on a plus de 2 transaction ouvert on va droit au catastrophe, car on s'est pas le nbr exact des places avant les modifications même rollback ne servira à rien... je crois
c'est pourquoi il faut vraiment savoir plus sur les transaction, les besoins, la différence entre ces modes

[Barbibulle]

normalement c'est le mode par défaut des transaction sous delphi (ib et fb);

Quel est le rapport avec votre besoin ?
Ce n'est pas parce qu'il y a une valeur par défaut que celle-ci doit être celle que vous devez utiliser. Même si je vous l'accorde la logique voudrait que la valeur par défaut d'un paramètre devrait être celui le plus utilisé...

[Barbibulle]

mais avec read_commit sa passe et on est obligé après de testé si les nbr des places n'est pas inférieur à 0,

C'est faux, et l'exemple donné par Makowski n'est pas tout à fait juste sur la fin car si la première transaction a été rollback elle se termine et donc on ne peut plus 'Réessayer de prendre 5 places'

S'il réessaye de prendre 5 places c'est en ouvrant une 3eme transaction. Si dans cette 3eme transaction, il relisait le nombre de place disponible il verrait qu'il n'en reste pas 5 et donc n'essayerai pas d'en soustraire 5.
Il a préféré ne pas le vérifier et laisser la contrainte mise sur la donnée le faire pour lui.

On voit bien qu'il n'y pas pas qu'une façon de faire pour que ça fonctionne, le tout étant de bien comprendre ce que l'on fait et doit faire

[edam]

S'il réessaye de prendre 5 places c'est en ouvrant une 3eme transaction. Si dans cette 3eme transaction, il relisait le nombre de place disponible il verrait qu'il n'en reste pas 5 et donc n'essayerai pas d'en soustraire 5.
Il a préféré ne pas le vérifier et laisser la contrainte mise sur la donnée le faire pour lui.

??? j'ai pas bien comprie
en plus pour l'example de makovski:

La première transaction regarde la disponibilité readcommitted READ
[(8,)]
La deuxième transaction regarde la disponibilité readcommitted READ
[(8,)]
La première transaction regarde la disponibilité readcommitted WRITE
[(8,)]
La deuxième transaction prend 5 places (pas encore committé) readcommitted WRITE
La première transaction prend 5 places et veux committer
(-901, 'isc_dsql_execute: \n lock conflict on no wait transaction\n deadlock\n update conflicts with concurrent update\n concurrent transaction number is 89')

là aussi j'ai pas compris pourquoi il y a une exception, avec une transaction readcommit?

[Barbibulle]

Firebird vous signale qu'une autre transaction (T2) est en train de modifier la donnée que vous essayez de mettre à jour.
Même si vous ne pouvez pas lire la nouvelle valeur (car vous êtes en readcommitted et l'autre transaction (T2) n'a pas encore Commit).

Lorsque l'autre transaction T2 fait le commit, la 1ere T1 peut lire la nouvelle valeur (mais aussi elle peut faire un update Directement en se basant sur l ancienne valeur... d'où l'utilité d'avoir mis une contrainte).

[edam]

Firebird vous signale qu'une autre transaction (T2) est en train de modifier la donnée que vous essayez de mettre à jour.
Même si vous ne pouvez pas lire la nouvelle valeur (car vous êtes en readcommitted et l'autre transaction (T2) n'a pas encore Commit).

Lorsque l'autre transaction T2 fait le commit, la 1ere T1 peut lire la nouvelle valeur (mais aussi elle peut faire un update Directement en se basant sur l ancienne valeur... d'où l'utilité d'avoir mis une contrainte).

j'ai essayer avec 2appli sur mon ordi, je modifi un article sur les deux au même temp, avec snapshot j'ai un erreur pour la 2éme commit , mais avec readcommit pas de probléme, et celle qui a commité la 1ére, bien sûr quand je réouvére ma table artile il charge les données modifier de l'autre Transaction (2éme)
ma transaction est ouver par

Code :

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

1
2
3
4
    with IBTransaction1.Params do
       begin
         Text:='read_committed'#13'rec_version'#13'nowait';
       end;

je crois que tu utilise no_rec_version à la plasse de rec_version

isc_tpb_rec_version: Avec ce paramètre une transaction peut dans tous les cas lire la dernière version stable d’un enregistrement, même s’il est en cours de modification par une autre transaction.
isc_tpb_no_rec_version: Avec ce paramètre une transaction doit attendre (isc_tpb_wait) - ou lever immédiatement une exception (isc_tpb_no_wait) - que toutes les autres transactions qui sont en train de modifier un enregistrement aient été validées (ou annulées) avant de pouvoir lire la dernière version de cet enregistrement.

[Barbibulle]

Je vais reprendre plus en détail l'exemple de Makowski

Soit T1 et T2 deux transactions read_committed, rec_version, nowait
Soit "Stock" le champs qui contient le nombre de pièce restante en stock d'un article donnée (ici on travaillera toujours sur le même article).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
Ouverture de T1 
 - T1 : La lecture de stock retourne 8
Ouverture de T2
 - T2 : La lecture de stock retourne 8
 - T2 : Mise à jour de update stock = Stock - 5 (Nouvelle valeur Stock =3)
 - T1 : Lecture de stock retourne 8
 - T2 : La lecture de stock retourne 3
 - T1 : Toute tentative de mise à jour de stock renverrai une exception  
        (lock conflict on no wait transaction  deadlock  
         update conflicts with concurrent update) 
        et ce depuis que T2 a mis à jour stock 
        (même si ce n'est pas encore commit) mettons qu'on ne ferme pas T1
 - Commit de T2
 - T1 : Mise à jour de update stock = Stock - 5 ça fonctionne car la valeur est commit et on est dans une transaction readcommit. (Nouvelle valeur Stock = -2 !!! )

Donc si vous avez mis comme Makowski une contrainte pour ne pas avoir un stock négatif vous aurez une exception de levée et la mise jour de faite par T1 impossible à commiter.
S'il n'y avait pas cette contrainte vous aurez un stock négatif

Maintenant prenons :
Soit T1 et T2 deux transactions concurrency, nowait (Snapshot)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
Ouverture de T1 
 - T1 : La lecture de stock retourne 8
Ouverture de T2
 - T2 : La lecture de stock retourne 8
 - T2 : Mise à jour de update stock = Stock - 5 (Nouvelle valeur Stock =3)
 - T1 : Lecture de stock retourne 8
 - T2 : La lecture de stock retourne 3
 - T1 : Toute tentative de mise à jour de stock renverrai une exception  
        (lock conflict on no wait transaction  deadlock  
         update conflicts with concurrent update) 
        et ce depuis que T2 a mis à jour stock 
        (même si ce n'est pas encore commit) mettons qu'on ne ferme pas T1
 - Commit de T2
 - T1 : Lecture de stock retourne 8
 - T1 : Toute tentative de mise à jour de stock renverrai une exception  
        (lock conflict on no wait transaction  deadlock  
         update conflicts with concurrent update) 
        et ce même si depuis T2 a fait son commit

Il devient donc également impossible d'avoir un stock négatif.
T1 doit être fermé (rollback) pour repartir sur une autre transaction T3 qui pourra lire la nouvelle valeur de stock.
L'inconvénient c'est que si T1 et toujours plus lent que T2, jamais T1 n'arrivera à mettre a jour le stock. (On sérialise les mises à jours)

L'autre gros inconvénient c'est s'il n'y avait pas de problème de stock. Reprenons les 2 exemples.

Si T1 ne veux retirer qu'une pièce. L'exemple 1 ne change pas jusqu au "Commit T2"
Puis :

Code :

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

1
2
3
 - T1 : Mise à jour de update stock = Stock - 1 (Nouvelle valeur Stock =2)
 - Commit de T1

Il n'y a eut aucun problème et la valeur du stock est correcte.

Dans l'exemple 2 (les snapshot) le résultat reste inchangé c'est à dire que T1 ne peut toujours pas mettre à jour stock...

En conclusion on voit bien qu'une snapshot va engendrer plus de deadlock et donc d'impossibilité de travailler en accès conccurent.

PS : Attention dans l'exemple 1 faire la mise à jour du stock comme je l'ai indiqué :
Update ... Set Stock = stock - X;
Ne surtout pas faire de
Update ... Set Stock = Y; !! dans ce cas là vous aurez un stock de faux

[edam]

merci ,
pour comprendre mon erreur sur readcommit j'ai dû enlevé commit(CommitRetaining) après l'envoi de donnée (post), , et là j'ai l'erreur que tu as spécifié,