Quand on a des accès concurrents, on utilise les transactions mais pas que

[badilou]

Doit-on aussi changer sa façon de programmer en delphi??

Doit-on faire attention à où mettre certains tests sur des objets de la base de données dans la partie client (delphi)?

Ou doit-on programmer comme d'habitude et les transactions font le reste pour assurer la cohérence des données?

Je dis ça parce que je viens de faire quelques expériences sur deux transactions utilisant un objet concurrent et je me suis rendu compte que malgrès l'utilisation des transactions (j'ai testé les modes [Snapshot] et [ReadCommitted]), les résultats obtenus étaient invraisemblables! Style le nombre de places libres dans un avion négatif!

J'en conclus que lorsque l'on programme en delphi en environnement concurrent, on ne réfléchit pas de la même manière qu'en mode monoposte, je me trompe?
Si c'est le cas, avez-vous des conseils à me donner ou de la doc à me proposer?

Merci!

[makowski]

parce que tu ne pousses pas la logique jusqu'au bout
si par exemple tu met une contrainte dans ta table disant que le nombre de place dans l'avion ne peut être négatif, ton problème est résolu
mais ce n'est pas un problème de niveau d'isolement de transaction
juste un problème de contrainte des données, ce n'est pas la même chose

[badilou]

les places d'avion n'étaient qu'un exemple. je peux vous trouver un autre cas ou il n'y aura pas de contraine possible à appliquer pour nous sortir de la! par exemple, la lecture fantôme que le [Committed] et le [Snapshot] permettent tout à fait (voir l'article : C:\Users\user\Desktop\site\articlestransactions [Firebird FR].mht) :

Exemple :

Transaction1

si (select count(*) from vol) = 0 alors
traitement1
sinon
traitement2

Commit transaction1

Transaction2

insert into vol values('3')
commit transaction2


Si la transaction1 s'exécute en premier suivie de la transaction2. Supposons que le que le test de la traansaction1 donne 0 (ie, pas d'enregistrements dans la table Vol) et qu'avant que le traitement1 ne débute, la transaction2 exécute son commit, le nombre d'enregistrements dans la table Vol augmentera de 1. La transaction1 exécutera malgrès cela le traitement1 au lieu du 2 et ça donnera forcément, un jour ou l'autre des résultats imprévisibles!

Certes, dans l'exemple on ne voit pas trop les eventuels dégats mais quand même, exécuter un traitement au lieu d'un autre ne peut pas être bon..

D'ailleurs, les modes snapshot et read commited peuvent laisser passer la lecture fantôme et l'ecriture biaisée(voir le même article). Inquiétant non?

A moins que j'ai mal compris..

[makowski]

mal compris pas vraiment, mais une connaissance que partielle oui
et inquiétant surement pas
il n'y a pas que snapshot et read committed, il y a aussi SNAPSHOT TABLE STABILITY
mais aussi le select for update
voir dans les cas necessitant un controle maximum, un select for update with lock

[badilou]

mal compris pas vraiment, mais une connaissance que partielle oui

je débute Mr makowski, je débute...

[edam]

ici