COMMIT ou COMMITRETAINING EN CLIENT/SERVEUR [FAQ]

**cantador** · 28/01/2008, 16h19

Bon, il faut diviser par 11 (saturday and sunday closed..)
ce qui donne 6772/11 = 615..
L'activité est un peu réduite, mais on fait qd 8 MEG de CA par an..

Enfin, rien de bien méchant..Je préfère effectuer quelques petits backup/restore de temps en temps
çà me fait sortir de mon bureau et voir les collègues !
Finallement le ComitRetaining a une vertu sociale insoupçonnée !!!

Merci quand même pour les informations Makowski et pour ton dévouement.

Ceci dit, de non côté, je fais mon possible afin de divulguer la bonne parole à propos de FIREBIRD.

@bientôt

**makowski** · 28/01/2008, 16h34

certes, mais le jour ou tu vas monter en charge, tu iras droit à la catastrophe et c'est tous les jours qu'il faudra faire un backup restore et encore cela ne suffira peut être pas
à bon entendeur salut

**jose.ignacio.agata** · 28/01/2008, 17h47

C:\Program Files\Firebird\Firebird_2_1\bin>gstat -h

Database header page information:
Flags 0
Checksum 12345
Generation 1072629
Page size 4096
ODS version 10.1
Oldest transaction 1072612
Oldest active 1072613
Oldest snapshot 1072613
Next transaction 1072614
Bumped transaction 1
Sequence number 0
Next attachment ID 6
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Oct 28, 2007 11:40:24

Variable header data:
*END*

Dans ce cas, cela veut dire que je perds 1 transaction ou le compteur est OK ? entre le 1072612 et le 1072613

**makowski** · 28/01/2008, 18h00

non il n'y a pas de problème
d'ailleurs, ce n'est pas la valeur absolue du gap qui pose problème, mais sa croissance continue sans jamais être réduit
une base fraichement restaurée a les valeurs suivantes :

Code :

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

1
2
3
4
	Oldest transaction	1 
	Oldest active		2 
	Oldest snapshot		2 
	Next transaction	5

Si un des modo voit ce fil, ce seait bien de le mettre en "Important", voir de le transformer en FAQ

**cantador** · 28/01/2008, 19h55

@makowski:

certes, mais le jour ou tu vas monter en charge, tu iras droit à la catastrophe

Mais pas du tout, bien au contraire, çà voudra dire que l'activité re-démarre et que les effectifs augmentent !
Mais tu vois c'est pas le scénario qui est prévu..
et même si cela devait se produire alors on le verrait arriver ..
...de loin

...et on aurait au moins 3 mois devant nous pour se retourner..

Je te rassure, la cata c'est pas pour demain.

@bientôt

**jose.ignacio.agata** · 28/01/2008, 20h36

dans le même genre d'idée, nous avons dans notre code du
commit work;
dans un composant ibquery qui lance cette 'requête' SQL au milieu de procédure s un peu longues....

Un avis ?

**makowski** · 28/01/2008, 21h07

dans ce cas, ibx doit terminer la transaction sur le commit (commit étant le raccourci de commit work) et immédiatement ouvrir une nouvelle transaction
pour poursuivre

**edam** · 04/08/2008, 10h52

Salut, désole de remonter cette discussion,
d'après cette long discussion. Alors quel est l’utilité de CommitRetaining ?
ici,
on a parlé d’utlisé 2 transaction ,

Le niveau d’isolement READ COMMITED est utile dans Firebird lorsqu’on souhaite utiliser des transactions longues en lecture seule (de préférence) comme expliqué dans l’article de Craiz Stunz Utilisation pratique des transactions longues il est parfois nécessaire de devoir conserver une transaction ouverte pendant longtemps 5) afin de rafraîchir périodiquement le contenu d’un contrôle connecté à la base de données (dans l’article de Craig Stunz il s’agit d’une application de Monitoring qui permet d’observer le comportement d’une base de données dans le cadre d’une utilisation réélle.)

une reste ouvert en lecture seul, et une pour la mise à jour, aussi, je veux savoir l’impact sur la base, surtout si la transaction en lecture seul est utilisé en 'read_committed' et reste ouvert

Code :

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

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

voilà, merci
autre chose Mr makowski, si tu utilise commit, est ce sa veux dire qu'utilise Tclientdataset avec des composant DB, ou autre chose??
j'aime bien avoir une idée d'un expert pour programmer une application de base de données
[Edit]

Envoyé par makowski

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.

tu peut cité d'autre ou même donnée un lien , merci

**edam** · 06/08/2008, 17h42

alors pas de Commentaire

**cantador** · 06/08/2008, 18h33

j'ai des transactions courtes et pourtant j'utilise CommitRetaining
car vu que j'ai un souci de débit de ligne et pour une question de rapidité
je préfère cette solution, même si cela présente quelques inconvénients.
Mais je ne vais pas recommencer le débat qui a eu lieu avec makowski et qui a faire le tour de la question il me semble.

Cantador

**edam** · 06/08/2008, 19h16

Envoyé par cantador

j'ai des transactions courtes et pourtant j'utilise CommitRetaining

et tu utlise ta transaction en snapshot ou read_committed??

**makowski** · 06/08/2008, 20h04

Envoyé par edam

autre chose Mr makowski, si tu utilise commit, est ce sa veux dire qu'utilise Tclientdataset avec des composant DB, ou autre chose??
j'aime bien avoir une idée d'un expert pour programmer une application de base de données

avec Delphi et FreePascal : UIB

Envoyé par edam

tu peut cité d'autre ou même donnée un lien , merci

www.ibphoenix.fr

**edam** · 06/08/2008, 20h18

Envoyé par makowski

avec Delphi et FreePascal : UIB

non, je parle pas des composant de connexion,
si tu utilise commit, ta transaction se férme, alors tes composant DB perds leur données, c'est pourquoi j'ai sité TClientDataset, surtout que les composant UDF sont uni directionnel (à part jvUIBDataset);
alors si c'est juste, tu l'utilise avec datasetprovider ou tu le fait manuellement (boucle de remplissage et de lecture) surtout pour des lignes d'une facture ou un bon

**makowski** · 06/08/2008, 23h00

je n'utilise pas de dataset
mais j'ai rien contre les gens qui en utilisent
mais le mieux reste UIB et un dataset en mémoire
si vraiment on veut un dataset

voir par exemple TGzFBCachedDataset
http://www.zoo-logique.org/made_in_d...8.18.2001.html

**cantador** · 06/08/2008, 23h14

@edam :

ReadCommited

Cantador

**edam** · 06/08/2008, 23h14

Envoyé par makowski

je n'utilise pas de dataset
mais j'ai rien contre les gens qui en utilisent
mais le mieux reste UIB et un dataset en mémoire
si vraiment on veut un dataset
voir par exemple TGzFBCachedDataset

TGzFBCachedDataset est un dataset en mémoir non??

**edam** · 06/08/2008, 23h19

Envoyé par cantador

@edam :

ReadCommited

Cantador

d'aprés ce lien

Dans Firebird et jusqu’à ce que des développements aient été entrepris dans ce sens, il est tout à fait déconseillé d’utiliser des transactions longues en lecture/écriture. Le problème est que l’OST (voir glossaire) reste collé à la transaction en lecture/écriture la plus ancienne (OAT) ce qui oblige le serveur à réaliser des opérations parfois très complexes de parcours des anciennes versions d’un enregistrement pour résoudre les conflits d’accès concurrents.