COMMIT ou COMMITRETAINING EN CLIENT/SERVEUR [FAQ]

[cantador]

Je pose la première pierre :

Pour ma part, le CommitRetaining est + rapide que le Commit.
Pourquoi ?
Dans cette option, les données de la base ne sont pas rafraîchies intégralement ce qui n'est pas le cas du Commit.
Evidemment, l'une ou l'autre des solutions a ses avantages et ses inconvénients.
Avec CommitRetaining, les opérations de validation sont bcp plus performantes mais les autres utilisateurs doivent rafraîchir les données pour voir les résultats.

C'est donc un choix stratégique qui dépend du contexte dans lequel on travaille.

Votre avis ?

cantador

[Cl@udius]

Salut

Envoyé par cantador

Evidemment, l'une ou l'autre des solutions a ses avantages et ses inconvénients.

Je n'argumenterai pas sur les avantages ou inconvénients. Ceci pour une raison simple, je m'interdis l'utilisation du CommitRetaining.
Partant du principe qu'une transaction ne doit rester ouverte que le temps strictement nécessaire aux traitements sur les données.

Que ce soit pour une requête Select ou une requête Action, je démarre la transaction, je traite les données, et immédiatement je commit.

@+ Claudius

[qi130]

La seule différence entre les 2 se situe sur la libération des ressources intrinsèques dédiées à la transaction...

isc_commit_retaining() writes all pending changes to the database, ends the current transaction without closing its record stream and cursors and without freeing its system resources, then starts a new transaction and assigns the existing record streams and system resources to the new transaction.

Le protocole Interbase étant très bavard, le fait de ne pas avoir à "négocier" l'allocation de ressources peut être avantageux.

Cependant, comme Cl@udius, j'évite. D'ailleurs, je m'arrange pour concevoir mes applis en ce sens.

Après, c'est un autre débat.

[cantador]

Le CommiRetaining conserve le contexte de la transaction mais sans tenir des autres en cours..
Bien sûr, je préfèrerai faire un Commit..

Ce qui m'étonne c'est la différence incroyable de la vitesse d'exécution.

Sinon pour les conséquences, il y a plus de peur que de mal...

(juste un détail je suis sous Firebird 1.5.4)

@bientôt

[makowski]

Envoyé par cantador

Ce qui m'étonne c'est la différence incroyable de la vitesse d'exécution.

Sinon pour les conséquences, il y a plus de peur que de mal...

J'ai un exemple qui montre tout le contraire
sur des gros volume le commit retaining est le pire qui soit pour les perfs et la santé de la base

[cantador]

@makowski:

"sur des gros volume le commit retaining est le pire qui soit"

Je suis très intéressé cette information.
Tu évoques "des gros volumes"..

Pourrais-tu m'indiquer leurs dimensions ?

merci par avance

[makowski]

bah, un petit exemple simple sur des volumes pas si gros que ça :
Avec commit retain:

Database header page information:
Oldest transaction 1
Oldest active 2
Oldest snapshot 2
Next transaction 5

Make a select count
200 rows time 0.0170.

Make 500*200 update with commit retain every 200
udate time 198.2554.

Database header page information:
Oldest transaction 6
Oldest active 7
Oldest snapshot 7
Next transaction 99308

Make a select count
200 rows time 35.4962.

Database header page information:
Oldest transaction 99308
Oldest active 7
Oldest snapshot 7
Next transaction 99309

Make a select count
200 rows time 0.0029.

Sans commit retain :

Database header page information:
Oldest transaction 1
Oldest active 2
Oldest snapshot 2
Next transaction 5

Make a select count
200 rows time 0.0095.

make 500*200 update with commit every 200
udate time 16.2761.

Database header page information:
Oldest transaction 503
Oldest active 504
Oldest snapshot 504
Next transaction 505

Make a select count
200 rows time 0.0054.

Database header page information:
Oldest transaction 503
Oldest active 504
Oldest snapshot 504
Next transaction 506

Make a select count
200 rows time 0.0035.

[jose.ignacio.agata]

bonjour à tous

nous utilisons souvent le commit retaining dans des instructions longues,avec usage de générateur - afin d'être certain que les derniers info saisies vont être les bonnes si on les utilise dans la même instruction.

Evidemment, on ferme la procédure par un commit.

Est-ce une erreur de programmation ?

De la meme manière, on finit l'appel à la dll dans le afterdispatch par un :
if IBTransaction.Active then IBTransaction.Commit;
if IBDatabase.Connected then IBDatabase.Close;

Est ce une bonne méthode... on fait cela depuis des lustres mais si ca se trouve, on est dans l'erreur...

Je précise qu'on developpe sous delphi 7 - avec webmodules.

[makowski]

Envoyé par jose.ignacio.agata

Est ce une bonne méthode... on fait cela depuis des lustres mais si ca se trouve, on est dans l'erreur...

Et à ton avis
mon exemple n'est pas assez éloquant ?
j'en ai d'autres comme ça des petits exemples sur la mauvaise gestion des transactions que je montre en formation.

[cantador]

@makowski :

Je souhaiterai avoir un bout de code qui a généré une partie de ses résultats:
Avec CommitRetainning
Sans CommitRetainning

car je ne suis pas certain que les techniques soient les mêmes.
(j'ai vu récemment CommitRetaining à la place de StartTransaction..)

merci par avance

[makowski]

Il n'y a pas plusieures manières de faire
on ouvre une transaction et on fait un commit ou un commit retain c'est tout
et ce quelque soit le type de transaction utilisée.

[cantador]

Comme çà au moins c'est clair

Reste à savoir pourquoi en ce qui me concerne, j'ai des temps de validation
10 fois + rapide avec CommitRetaining qu'avec Commit et ce sur la zone en câblage direct avec le serveur..
Evidemment pour les sites distants c'est encore pire.

@+

[makowski]

Envoyé par cantador

Comme çà au moins c'est clair

Reste à savoir pourquoi en ce qui me concerne, j'ai des temps de validation
10 fois + rapide avec CommitRetaining qu'avec Commit et ce sur la zone en câblage direct avec le serveur..
Evidemment pour les sites distants c'est encore pire.

@+

parce que tu garde le contexte de la transactions et dans certains cas cela peut être utile, mais cela peut être rapide sur le coup et entrainer des dégradation de perfs plus tard, faire grossir inutilement les données périmées à collecter et donc obliger à faire des restores, alors qu'une base bien gérée n'a jamais besoin de connaitre de restauration, sauf en cas de changement de version du serveur.

je serais tout de même curieux de voir les stats de la base après une journée de fonctionnement ...

[cantador]

je dis ok.
quel est le fichier que tu veux ?

@+

[makowski]

la sortie d'un gstat -h

[cantador]

ok, je te le transmets dès que possible.

@bientôt

[cantador]

En fait, j'ai tapé la commande complète :

gstat -h <mabase> -user sysdba -password monpassword

et voilà le résultat :

Database header page information:
Flags 0
Checksum 12345
Generation 7564
Page size 4096
ODS version 10.1
Oldest transaction 464
Oldest active 6666
Oldest snapshot 6651
Next transaction 6773
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jan 14, 2008 14:05:55
Attributes

Variable header data:
Sweep interval: 20000
*END*

le 14/01/2008 m'étonne un peu, à moins que ce ne soit la date de mon dernier backup/restore..

@+

[cantador]

j'ai lancé cette commande sur mon poste en local après avoir recopié la base réseau en local..

[makowski]

Envoyé par cantador

j'ai lancé cette commande sur mon poste en local après avoir recopié la base réseau en local..

Pardon ?
la base était en activité ?

[makowski]

Envoyé par cantador

Oldest transaction 464
Oldest active 6666
Oldest snapshot 6651
Next transaction 6773
Creation date Jan 14, 2008 14:05:55

Creation date : date de création de la base (dernière restauration)

Next transaction 6773 soit 6772 transactions depuis cette date soit 450 transactions par jour, cette base est faiblement sollicitée

Oldest transaction (OIT) 464
Oldest active (OAT) 6666
gap : 6202

ceci dit il semble bien (et ce n'est pas une surprise avec les commit retain) que la collecte des données périmées ne peut pas se faire, à force, ce gap va continuer à grossir et créer des pertes de performances, mais comme la base est peu sollicité, tu ne t'en rend pas vraiment compte ou alors seulement au bout d'un bon moment, ce qui t'amène pour corriger cela à faire un backup et un restore pour que tout rentre dans l'ordre, alors que normalement avec une base comme ça un restore qu'à chaque changement de version majeur de Firebird devrait suffire.
Voilà vite fait.