firebird-fr-support — support en franšais sur Firebird

Re: [Firebird-fr-support] [Fwd: Re: Interbase, Firebird et transactions [long...]]

[<be...@en...>]

----- Original Message ----- 
From: "Philippe Makowski" <mak...@fi...>
To: <fir...@li...>
Sent: Wednesday, April 13, 2005 9:14
Subject: Re: [Firebird-fr-support] [Fwd: Re: Interbase, Firebird et
transactions [long...]]


Le 13/04/2005 14:42, Bérenger Enselme a dit :
> "Gestion "consistante" de l'accès concurrent : si deux threads écrivent
> une même valeur au même endroit :
>
> updates comptes set
>  solde = solde + 2
> where client='PIERRE';
>
> Il n'y a pas le choix : il faut passer en mode SNAPSHOT TABLE STABILITY"
>
> ça c'est dur. est-ce que tu as une adresse de là où il est expliqué ce qui
> se passe ?
>
"c'est pas un peu décrit dans les releases notes là où on parle des WITH
LOCK ?"

D'après moi le WITH LOCK n'est utile qu'en READ COMMIITTED pour des
opérations du type: lecture d'une valeur (SELECT), incrémentation par
l'appli cliente, UPDATE avec la nouvelle valeur. Sinon je ne vois pas, mais
je peux facilement passer à côté de quelque chose.

Donc je n'arrive pas à trouver le pourquoi de la nécessité du "TABLE
STABILITY" dans l'exemple de Pierre Y.

Re: [Firebird-fr-support] [Fwd: Re: Interbase, Firebird et transactions [long...]]

[<be...@en...>]

"C'est un truc que je ne suis pas absolument certain d'avoir compris :
effectivement MGA (c'est son nom anglais) est à la base de tout, n'empêche,
quand les choses deviennent compliquées (plusieurs transactions qui essaient
d'écrire la même donnée) des verrous sont posés par le serveur pour demander
aux transactions d'attendre que celle qui a pris le verrou ait fini sont
travail et le rende. J'ai du mal à m'imaginer le foncionnement des verrous
et la manière dont ils sont posés/partagés entre les transactions selon leur
niveau d'isolement."

Je ne crois pas qu'il y ait de verrous à proprement parler. Si tu essaies de
modifier un record et que tu tombes sur une version qui correspond à une
transaction en cours, tu sais que tu es cuit !

"Sauf que la moindre requête exécutée vers le serveur provoque en cascade
l'exécution de plusieurs centaines d'autres requêtes (pour lire et valider
les métadonnées en fonction du SQL qui a été parsé)"

Requêtes, oui, mais transactions, non.

 "l'OAT est un truc qui
augmente relativement vite je trouve, dans un environnement massivement
muti-tiers il n'est pas impensable d'avoir plusieurs milliers de
transactions par seconde."

C'est un peu un cas particulier de l'utilisation de FB, qu'on voit plus
souvent utilisé pour des applis C/S, mais c'est effectivement possible.

"Il n'y a pas de E, en anglais le sigle est ACID, je le traduit tel quel en
français pour le comique de la phrase. D'habitude je le met en minuscule :
ACIDe, ACIDité..."

Oui je faisais du mauvais esprit, désolé.

"Au niveau SNAPSHOT on choppe une exception. "

Absolument. Heu, même si on est en wait ?

Mais c'était sur le UPDATE x = x + 2 que je me posais des questions. Et je
n'ai pas encore regardé ce qu'a posté Philippe ici.

"Peut-être faut-il que je creuse encore, quelqu'un est-il prêt à m'aider
dans
cette quête de la transaction idéale ?"

Dans la limite de mes toutes petites compétences théoriques, oui, mais je ne
sais pas si on va aller très loin !










----- Original Message ----- 
From: "Pierre Y." <zed...@ne...>
To: <fir...@li...>
Sent: Wednesday, April 13, 2005 11:56
Subject: RE: [Firebird-fr-support] [Fwd: Re: Interbase, Firebird et
transactions [long...]]


> En lisant ce paragraphe, on dirait que Read Commited permet d'éviter
> l'infâme problème des chaînes de transactions qui s'allongent (vous savez
> le
> creux OIT/OAT). Mais est-ce vraiment le cas  quand on est en
> lecture/écriture ? Dans mes souvenirs, non, mais je peux me tromper bien
> entendu !

Le problème des transactions longues READ COMMITED en lecture écriture c'est
surtout la possibilité d'obtenir des anomalies de lecture (par définition en
mode READ COMMITED la lecture n'est pas répétable) et c'est justement pour
les éviter qu'on est obligé de changer de niveau d'isolement avec les
"inconvénients" que ca implique.

> Et je crois qu'il est un peu exagéré de dire que l'architecture MG ne joue
> plus dans ce cas. Elle joue, pas le choix, c'est à la base de tout, mais
> d'une façon différente.

C'est un truc que je ne suis pas absolument certain d'avoir compris :
effectivement MGA (c'est son nom anglais) est à la base de tout, n'empêche,
quand les choses deviennent compliquées (plusieurs transactions qui essaient
d'écrire la même donnée) des verrous sont posés par le serveur pour demander
aux transactions d'attendre que celle qui a pris le verrou ait fini sont
travail et le rende. J'ai du mal à m'imaginer le foncionnement des verrous
et la manière dont ils sont posés/partagés entre les transactions selon leur
niveau d'isolement.

> "Pourquoi faire des transactions de monitoring longues plutôt que plein
> de transactions courtes ? Pour ne pas consommer d'ID de transaction.
> Même si les nombre d'ID de transactions disponibles est très élevé
> (plusieurs milliards), quand on arrive au bout, on prend une erreur
> dans la tête et il faut faire un backup/restore pour nettoyer les
> transactions échues."
>
> A une transaction toutes les secondes, ça prend 136 ans pour se prendre
> l'erreur dont tu parles dans la tête. J'espère que tu fais des backups un
> peu plus souvent que ça ;-))) ! Pour moi cet argument ne tient pas.

Sauf que la moindre requête exécutée vers le serveur provoque en cascade
l'exécution de plusieurs centaines d'autres requêtes (pour lire et valider
les métadonnées en fonction du SQL qui a été parsé) l'OAT est un truc qui
augmente relativement vite je trouve, dans un environnement massivement
muti-tiers il n'est pas impensable d'avoir plusieurs milliers de
transactions par seconde.

> "Et pourquoi ne fait on pas de transactions d'écriture longues (hormis
> celles nécessaires pour copier une table dans une autre, copier une
> table entre deux bases de données, faire un restore...) : parcequ'une
> transaction doit être ACIDE ;-)"
>
> C'est quoi le E ? Ecstasy ? Intéressant...

Il n'y a pas de E, en anglais le sigle est ACID, je le traduit tel quel en
français pour le comique de la phrase. D'habitude je le met en minuscule :
ACIDe, ACIDité...

> "Gestion "consistante" de l'accès concurrent : si deux threads écrivent
> une même valeur au même endroit :
>
> updates comptes set
>  solde = solde + 2
> where client='PIERRE';
>
> Il n'y a pas le choix : il faut passer en mode SNAPSHOT TABLE STABILITY"
>
> ça c'est dur. est-ce que tu as une adresse de là où il est expliqué ce qui
> se passe ?

Comme je l'explique plus haut, j'affirme (peut-être à tord) sans être
certain. D'après les gourous de Firebird le niveau SERIALIZABLE est inutile
car trop coûteux. Le plus haut niveau proposé par Firebird est
isc_tpb_consistency qui correspondrait à "SNAPSHOT TABLE STABILITY" et je
crois pouvoir dire que ce phénomène qu'on appelle "modifications perdues
(lost updates)" ne peut pas se produire à ce niveau là. Ni au niveau
SNAPSHOT d'ailleurs. Grâce aux locks implicites que Firebird pose sur les
enregistrements en cours de modification.

Ce qu'on peut avoir comme problème au niveau SNAPSHOT c'est des violations
de contrainte (les phénomènes P5A et P5B dans le document "critique des
niveaux d'isolement des transactions dans la norme SQL ANSI") qui s'achèvent
pas une exception levée par le serveur "[...machin...] check that precludes
excecution of subsequent statements"

On peut imaginer un Historique de transaction comme ça en supposant que C()
est une contrainte sur les enregistrements x et y (x=y, relation clé
étrangère) :

H : r1[x] ... w2[y] ... w1[x] ...  (c2 ou c1 dans n'importe quel ordre)

Où r représente une opération de lecture, w une opération d'écriture et c le
commit. 1 et 2 sont les deux transactions ; r1[x] signifie que T1 lit la
donnée x (une clé primaire ou étrangère puisque x=y) et w2[y] que T2 écrit
la valeur de la donnée y.

Au niveau SNAPSHOT on choppe une exception. Au niveau SERIALIZABLE c'est
impossible parceque c'est ça qui va se passer :

H : r1[x] w1[x] c1 w2[y] c2

Peut-être faut-il que je creuse encore, quelqu'un est-il prêt à m'aider dans
cette quête de la transaction idéale ?

A+

Pierre



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick
_______________________________________________
Firebird-fr-support mailing list
Fir...@li...
https://lists.sourceforge.net/lists/listinfo/firebird-fr-support

RE: [Firebird-fr-support] [Fwd: Re: Interbase, Firebird et transactions [long...]]

[Pierre Y. <zed...@ne...>]

> En lisant ce paragraphe, on dirait que Read Commited permet d'=E9viter
> l'inf=E2me probl=E8me des cha=EEnes de transactions qui s'allongent =
(vous savez
> le
> creux OIT/OAT). Mais est-ce vraiment le cas  quand on est en
> lecture/=E9criture ? Dans mes souvenirs, non, mais je peux me tromper =
bien
> entendu !

Le probl=E8me des transactions longues READ COMMITED en lecture =
=E9criture c'est
surtout la possibilit=E9 d'obtenir des anomalies de lecture (par =
d=E9finition en
mode READ COMMITED la lecture n'est pas r=E9p=E9table) et c'est =
justement pour
les =E9viter qu'on est oblig=E9 de changer de niveau d'isolement avec =
les
"inconv=E9nients" que ca implique.
=20
> Et je crois qu'il est un peu exag=E9r=E9 de dire que l'architecture MG =
ne joue
> plus dans ce cas. Elle joue, pas le choix, c'est =E0 la base de tout, =
mais
> d'une fa=E7on diff=E9rente.

C'est un truc que je ne suis pas absolument certain d'avoir compris :
effectivement MGA (c'est son nom anglais) est =E0 la base de tout, =
n'emp=EAche,
quand les choses deviennent compliqu=E9es (plusieurs transactions qui =
essaient
d'=E9crire la m=EAme donn=E9e) des verrous sont pos=E9s par le serveur =
pour demander
aux transactions d'attendre que celle qui a pris le verrou ait fini sont
travail et le rende. J'ai du mal =E0 m'imaginer le foncionnement des =
verrous
et la mani=E8re dont ils sont pos=E9s/partag=E9s entre les transactions =
selon leur
niveau d'isolement.

> "Pourquoi faire des transactions de monitoring longues plut=F4t que =
plein
> de transactions courtes ? Pour ne pas consommer d'ID de transaction.
> M=EAme si les nombre d'ID de transactions disponibles est tr=E8s =
=E9lev=E9
> (plusieurs milliards), quand on arrive au bout, on prend une erreur
> dans la t=EAte et il faut faire un backup/restore pour nettoyer les
> transactions =E9chues."
>=20
> A une transaction toutes les secondes, =E7a prend 136 ans pour se =
prendre
> l'erreur dont tu parles dans la t=EAte. J'esp=E8re que tu fais des =
backups un
> peu plus souvent que =E7a ;-))) ! Pour moi cet argument ne tient pas.

Sauf que la moindre requ=EAte ex=E9cut=E9e vers le serveur provoque en =
cascade
l'ex=E9cution de plusieurs centaines d'autres requ=EAtes (pour lire et =
valider
les m=E9tadonn=E9es en fonction du SQL qui a =E9t=E9 pars=E9) l'OAT est =
un truc qui
augmente relativement vite je trouve, dans un environnement massivement
muti-tiers il n'est pas impensable d'avoir plusieurs milliers de
transactions par seconde.

> "Et pourquoi ne fait on pas de transactions d'=E9criture longues =
(hormis
> celles n=E9cessaires pour copier une table dans une autre, copier une
> table entre deux bases de donn=E9es, faire un restore...) : =
parcequ'une
> transaction doit =EAtre ACIDE ;-)"
>=20
> C'est quoi le E ? Ecstasy ? Int=E9ressant...

Il n'y a pas de E, en anglais le sigle est ACID, je le traduit tel quel =
en
fran=E7ais pour le comique de la phrase. D'habitude je le met en =
minuscule :
ACIDe, ACIDit=E9...
=20
> "Gestion "consistante" de l'acc=E8s concurrent : si deux threads =
=E9crivent
> une m=EAme valeur au m=EAme endroit :
>=20
> updates comptes set
>  solde =3D solde + 2
> where client=3D'PIERRE';
>=20
> Il n'y a pas le choix : il faut passer en mode SNAPSHOT TABLE =
STABILITY"
>=20
> =E7a c'est dur. est-ce que tu as une adresse de l=E0 o=F9 il est =
expliqu=E9 ce qui
> se passe ?

Comme je l'explique plus haut, j'affirme (peut-=EAtre =E0 tord) sans =
=EAtre
certain. D'apr=E8s les gourous de Firebird le niveau SERIALIZABLE est =
inutile
car trop co=FBteux. Le plus haut niveau propos=E9 par Firebird est
isc_tpb_consistency qui correspondrait =E0 "SNAPSHOT TABLE STABILITY" et =
je
crois pouvoir dire que ce ph=E9nom=E8ne qu'on appelle "modifications =
perdues
(lost updates)" ne peut pas se produire =E0 ce niveau l=E0. Ni au niveau
SNAPSHOT d'ailleurs. Gr=E2ce aux locks implicites que Firebird pose sur =
les
enregistrements en cours de modification.

Ce qu'on peut avoir comme probl=E8me au niveau SNAPSHOT c'est des =
violations
de contrainte (les ph=E9nom=E8nes P5A et P5B dans le document "critique =
des
niveaux d'isolement des transactions dans la norme SQL ANSI") qui =
s'ach=E8vent
pas une exception lev=E9e par le serveur "[...machin...] check that =
precludes
excecution of subsequent statements"

On peut imaginer un Historique de transaction comme =E7a en supposant =
que C()
est une contrainte sur les enregistrements x et y (x=3Dy, relation cl=E9
=E9trang=E8re) :

H : r1[x] ... w2[y] ... w1[x] ...  (c2 ou c1 dans n'importe quel ordre)

O=F9 r repr=E9sente une op=E9ration de lecture, w une op=E9ration =
d'=E9criture et c le
commit. 1 et 2 sont les deux transactions ; r1[x] signifie que T1 lit la
donn=E9e x (une cl=E9 primaire ou =E9trang=E8re puisque x=3Dy) et w2[y] =
que T2 =E9crit
la valeur de la donn=E9e y.

Au niveau SNAPSHOT on choppe une exception. Au niveau SERIALIZABLE c'est
impossible parceque c'est =E7a qui va se passer :

H : r1[x] w1[x] c1 w2[y] c2

Peut-=EAtre faut-il que je creuse encore, quelqu'un est-il pr=EAt =E0 =
m'aider dans
cette qu=EAte de la transaction id=E9ale ?

A+

Pierre

Re: [Firebird-fr-support] [Fwd: Re: Interbase, Firebird et transactions [long...]]

[Philippe M. <mak...@fi...>]

Le 13/04/2005 14:42, B=E9renger Enselme a dit :
> "Gestion "consistante" de l'acc=E8s concurrent : si deux threads =E9cri=
vent
> une m=EAme valeur au m=EAme endroit :
>=20
> updates comptes set
>  solde =3D solde + 2
> where client=3D'PIERRE';
>=20
> Il n'y a pas le choix : il faut passer en mode SNAPSHOT TABLE STABILITY=
"
>=20
> =E7a c'est dur. est-ce que tu as une adresse de l=E0 o=F9 il est expliq=
u=E9 ce qui
> se passe ?
>=20
c'est pas un peu d=E9crit dans les releases notes l=E0 o=F9 on parle des =
WITH
LOCK ?
(1.5) Verrous explicites
Nickolay Samofatov
pages 14 =E0 16 dans la version en fran=E7ais
Firebird_v15.108_ReleaseNotesFrench.pdf
et 15 =E0 17 en anglais Firebird_v1.5.ReleaseNotes.pdf


--=20
Philippe Makowski

Firebird serveur SQL open-source en fran=E7ais http://firebird-fr.eu.org

Ma cl=E9 PGP : http://makowski.eu.org/pgpkey.html

Re: [Firebird-fr-support] [Fwd: Re: Interbase, Firebird et transactions [long...]]

[<be...@en...>]

Salut Pierre & les autres ! Merci pour le beau boulot !

"Il arrive que parfois on ait besoin de faire des transactions longues,
par exemple pour faire du monitoring sur une table : On ouvre une
transaction mais on a besoin de voir les enregistrements commités
depuis que la transaction a été ouverte : il faut alors baisser le
niveau d'isolement des transactions en utilisant READ COMMITED. Dans ce
cas ce n'est plus l'architecture multi-générationnelle qui joue mais
une architecture à base de réservation de ressources. Ce que tout le
monde ignore c'est que Firebird permet de préciser si une transaction
va être en lecture seule ou en lecture écriture."

En lisant ce paragraphe, on dirait que Read Commited permet d'éviter
l'infâme problème des chaînes de transactions qui s'allongent (vous savez le
creux OIT/OAT). Mais est-ce vraiment le cas  quand on est en
lecture/écriture ? Dans mes souvenirs, non, mais je peux me tromper bien
entendu !

Et je crois qu'il est un peu exagéré de dire que l'architecture MG ne joue
plus dans ce cas. Elle joue, pas le choix, c'est à la base de tout, mais
d'une façon différente.

"Pourquoi faire des transactions de monitoring longues plutôt que plein
de transactions courtes ? Pour ne pas consommer d'ID de transaction.
Même si les nombre d'ID de transactions disponibles est très élevé
(plusieurs milliards), quand on arrive au bout, on prend une erreur
dans la tête et il faut faire un backup/restore pour nettoyer les
transactions échues."

A une transaction toutes les secondes, ça prend 136 ans pour se prendre
l'erreur dont tu parles dans la tête. J'espère que tu fais des backups un
peu plus souvent que ça ;-))) ! Pour moi cet argument ne tient pas.

"Et pourquoi ne fait on pas de transactions d'écriture longues (hormis
celles nécessaires pour copier une table dans une autre, copier une
table entre deux bases de données, faire un restore...) : parcequ'une
transaction doit être ACIDE ;-)"

C'est quoi le E ? Ecstasy ? Intéressant...

"Gestion "consistante" de l'accès concurrent : si deux threads écrivent
une même valeur au même endroit :

updates comptes set
 solde = solde + 2
where client='PIERRE';

Il n'y a pas le choix : il faut passer en mode SNAPSHOT TABLE STABILITY"

ça c'est dur. est-ce que tu as une adresse de là où il est expliqué ce qui
se passe ?

Pour tout le reste, parfait !

[Firebird-fr-support] [Fwd: Re: Interbase, Firebird et transactions [long...]]

[Philippe M. <mak...@fi...>]

[forward pour un archivage ]

> je me souviens plus pr=E9cis=E9ment du pourquoi de la chose, mais en de=
mandant=20
> sur le ng interbase Ann, Philippe ou d'autre devraient pouvoir redonner=
=20
> l'explication

Je suis en train d'=E9crire un article l=E0 dessus.

Je vous r=E9sume la situation : On DOIT faire des transactions pour
toutes les requ=EAtes qu'on envoie =E0 la base de donn=E9es.

Et le COMMIT (MARNEUS ! Tu suis au lieu de bailler aux corneilles !)
permet de valider la transaction, il faut savoir que Firebird utilise
une architecture de conctr=F4le des acc=E8s concurrents
multi-g=E9n=E9rationnelle : c'est =E0 dire que pour chaque transaction
ouverte, le syst=E8me cr=E9e une nouvelle "version" des enregistrements
auxquels on acc=E8de. De cette mani=E8re il n'y a pas de probl=E8mes de
verrous =E0 poser sur les objets de la base (les tables, les pages
d'index,...) pour =E9viter que des =E9crivains ne viennent rendre obsol=E8=
tes
les enregistrements que l'on est en train de lire. C'est le probl=E8me
des niveaux d'isolement des transactions. Firebird, par d=E9faut pour ses
transactions utilise le niveau d'isolement SNAPSHOT (qui veut bien dire
ce qu'il pr=E9tend =EAtre : une "photo" de la base) qui isole compl=E8tem=
ent
chaque transaction de toutes les autres. Donc les ph=E9nom=E8nes provoqu=E9=
s
par des acc=E8s concurrents "mal" g=E9r=E9s ne peuvent pas survenir (lect=
ure
ou =E9criture sauvage, enregistrements fant=F4mes, pertes de modification=
s,
lecture et =E9criture biais=E9e... tout est dans mon article).

Donc m=EAme quand on fait une lecture, Firebird cr=E9e un snapshot des
enregistrements afin que la lecture soit CONSISTANTE et REPETABLE !!!!
C'est LE plus important dans le cas d'acc=E8s concurrents. On doit
pouvoir REFAIRE la m=EAme lecture dans le contexte d'une transaction et
que le r=E9sultat soit IDENTIQUE.

Alors conclusion : A la fin de la lecture il faut remettre les choses
d'aplomb et par cons=E9quent valider la transaction par un COMMIT. Si
vous faites un ROLLBACK, firebird qui est un fieff=E9 mariole, d=E9tecter=
a
que vous n'avez apport=E9 AUCUNE modification =E0 la base de donn=E9es et
transformera votre ROLLBACK en COMMIT. Parceque le co=FBt d'ex=E9cution d=
u
ROLLBACK est =E9norme, Firebird doit parcourir la liste des transactions
ouvertes et la liste des diff=E9rentes versions d'enregistrements pour
restaurer la bonne version visible par les transactions qui d=E9marreront
ensuite.

Cas particulier : le niveau d'isomement READ COMMITED vs SNAPSHOT et
les transactions longues. Attention, je vais en choquer plus d'un.

Il arrive que parfois on ait besoin de faire des transactions longues,
par exemple pour faire du monitoring sur une table : On ouvre une
transaction mais on a besoin de voir les enregistrements commit=E9s
depuis que la transaction a =E9t=E9 ouverte : il faut alors baisser le
niveau d'isolement des transactions en utilisant READ COMMITED. Dans ce
cas ce n'est plus l'architecture multi-g=E9n=E9rationnelle qui joue mais
une architecture =E0 base de r=E9servation de ressources. Ce que tout le
monde ignore c'est que Firebird permet de pr=E9ciser si une transaction
va =EAtre en lecture seule ou en lecture =E9criture. Et plus finement
encore, Firebird permet aussi de pr=E9ciser "en d=E9tail" ce que l'on veu=
t
faire de chaque table de la base : ce sont les options isc_tpb_read,
isc_tpb_write, isc_tpc_lock_read et isc_tpb_lock_write du Transaction
Parameter Block de Firebird. A ceux l=E0 on ajoute : isc_tpb_shared,
isc_tpb_protected qui permettent de d=E9finir quelle sorte de v=E9rrous o=
n
veut poser sur les objets qu'on r=E9serve.

Tout =E7a mis ensemble permet de cr=E9er des transaction LONGUES (tr=E8s
longues m=EAme : plusieurs jours s'il le faut) sans pour autant p=E9nalis=
er
les performances. Il suffit de bien les utiliser en pr=E9cisant si elles
sont en lecture seule ou en lecture =E9criture.

Et c'est =E0 que je vais foutre le bordel par rapport =E0 ce que
j'affirmais il y a seulement quelques jours : dans le cas d'une
transaction longue en lecture =E9criture au niveau d'isolement READ
COMMITED, il faut utiliser... CommitRetaining de temps en temps pour
que le serveur prenne le temps de lib=E9rer les verrous, =E9crire les
enregistrements, valider la transaction TOUT EN VOUS RENDANT LE
CONTEXTE DE LA TRANSACTION, c'est =E0 dire que les requ=EAtes ouvertes
restent ouvertes.

Il est impensable d'imaginer des transactions longues au niveau
d'isolement SNAPSHOT vu le bordel que devra faire le serveur pour
retrouver les bonnes versions des enregistrements lorsque la
transaction longue sera valid=E9e, m=EAme s'il ne s'agit que d'une requ=EA=
te
de lecture.

Pourquoi faire des transactions de monitoring longues plut=F4t que plein
de transactions courtes ? Pour ne pas consommer d'ID de transaction.
M=EAme si les nombre d'ID de transactions disponibles est tr=E8s =E9lev=E9
(plusieurs milliards), quand on arrive au bout, on prend une erreur
dans la t=EAte et il faut faire un backup/restore pour nettoyer les
transactions =E9chues.

Et pourquoi ne fait on pas de transactions d'=E9criture longues (hormis
celles n=E9cessaires pour copier une table dans une autre, copier une
table entre deux bases de donn=E9es, faire un restore...) : parcequ'une
transaction doit =EAtre ACIDE ;-)

Atomicit=E9, Consistance, Isolement et Durabilit=E9 :

Atomicit=E9 : signifie que vues de l'ext=E9rieur, les op=E9rations r=E9al=
is=E9es
dans le cadre d'une transaction sont =E9quivalentes =E0 une seule op=E9ra=
tion :
quand la transaction est valid=E9e on bascule d'un =E9tat stable =E0 un a=
utre
=E9tat stable "d'un coup".

Consistance : si une transaction =E9choue, c'est toutes les op=E9rations
qui sont annul=E9es d'un bloc, on ne fait pas de demi mesure en ne
validant que les op=E9rations qui auraient r=E9ussi.

Isolement : les op=E9rations r=E9alis=E9es dans le cadre d'une transactio=
n
sont idol=E9es "physiquement" de ce qui peut =EAtre fait dans d'autres
transactions, ce param=E8tre est variable et consistue ce qu'on appelle
le "niveau d'isolement" d'une transaction.

Durabilit=E9 : Quand une transaction est valid=E9e, les donn=E9es =E9crit=
es
consistituent un =E9tat stable de la base de donn=E9es : on peut rebooter
la machine, tuer le serveur... au red=E9marrage c'est cet =E9tat stable q=
ui
sera conserv=E9.

Donc :

Transactions longues en lecture : utiliser isc_tpc_read_commited,
isc_tpb_wait, isc_tpb_rec_version (niveau d'isolement READ COMMITED)

avec sp=E9cification du type de transaction : isc_tpb_read

Transactions courtes (lecture/=E9criture) : utiliser isc_tpb_concurrency
et isc_tpb_write (par d=E9faut)

Gestion "consistante" de l'acc=E8s concurrent : si deux threads =E9criven=
t
une m=EAme valeur au m=EAme endroit :

updates comptes set
 solde =3D solde + 2
where client=3D'PIERRE';

Il n'y a pas le choix : il faut passer en mode SNAPSHOT TABLE STABILITY
avec les param=E8tres isc_tpb_consistency et demander explicitement des
verrous sur les tables auxquelles on va acc=E8der :

On peut demander dex verrous "partag=E9s" ou des verrous "prot=E9g=E9s",
selon l'option choisie Firebird autorisera ou pas l'acc=E8s =E0 un
enregistrement ou =E0 une table selon les modifications qui auront =E9t=E9
apport=E9es par la premi=E8re transaction qui y a acc=E9d=E9. Les param=E8=
tres
sont isc_tpb_shared et isc_tpb_protected.

Pour la r=E9servation des tables : isc_tpb_lock_read si l'on garanti au
serveur qu'on acc=E8dera =E0 une table qu'en lecture seule ou
isc_tpb_lock_write si l'on demande au serveur de d=E9poser pour nous un
verrou en lecture/=E9criture. Il faut pr=E9ciser la liste des tables
r=E9serv=E9es dans l'un ou l'autre mode en les s=E9parant par une virgule=
.
L'=E9diteur de transactions d'UIB sait faire =E7a.

Il existe un niveau d'isolement ultime qu'on appelle SERIALIZABLE (par
d=E9faut dans MSSQL Server) qui permet de garantir que l'ex=E9cution des
op=E9rations dans des transactions concurrentes sera vue comme
l'ex=E9cution en s=E9rie de ses transactions et des op=E9rations qu'elle
contiennent. Ca permet de r=E9soudre tous les probl=E8me d'acc=E8s
concurrents puisqu'il n'y a plus d'acc=E8s concurrents : une sorte de
spooler de transactions se charge de les ex=E9cuter les unes apr=E8s les
autres.

Ce mode n'existe pas dans Firebird mais on peut le simuler :
isc_tpb_consistency + isc_tpb_wait + isc_tpb_write + isc_tpb_protected
+ isc_tpb_lock_write avec la liste de TOUTES les tables de la base.

Normalement avec Firebird on n'a jamais besoin de ce mode l=E0, puisque
=E7a co=FBte TRES cher en temps d'ex=E9cution mieux vaut penser correctem=
ent
son application et sa base de donn=E9es que d'utiliser ce genre de
marteau pilon pour =E9craser des mouches.

Finalement.

R=E9fl=E9chissez bien aux transactions que vous utilisez dans votre base =
de
donn=E9es, imaginez les acc=E8s concurrents, les chevauchements dans le
temps afin de bien choisir ce qui doit se passer dans vos transactions
et en particulier leur niveau d'isolement.

Pas de transaction globale pour toute l'application. Mais pas de
transaction syst=E9matiquement pour chaque requ=EAte sql envoy=E9e au
serveur, pensez en terme d'atomicit=E9 : je veux cr=E9er un article mais
pour =E7a je dois =E9crire dans 25 tables, c'est l'=E9criture dans 25 tab=
les
qui consititue UNE transaction, si ca =E9choue, je dois annuler toutes
les modifications qui ont =E9t=E9 faites dans chacunes des tables avant l=
e
plantage. Pas juste la moiti=E9 parceque pour respecter le pr=E9cepte des
transactions hyper courtes vous avez cr=E9=E9 une transaction par requ=EA=
te
SQL.

Si ce n'est pas clair ou s'il manque des infos, dites le j'en
profiterai pour relire mon article et v=E9rifier que ce que vous demandez
est bien d=E9taill=E9 dedans.

Merci d'avoir tenu le coup ;-)

Pierre

--=20
Philippe Makowski

Firebird serveur SQL open-source en fran=E7ais http://firebird-fr.eu.org

Ma cl=E9 PGP : http://makowski.eu.org/pgpkey.html

Re: [Firebird-fr-support] Re: Documentation Firebird

[Philippe M. <mak...@fi...>]

Le 06/04/2005 08:55, Philippe Makowski a dit :
> Bonjour,
>=20
>>J'aurai voulu savoir si vous aviez une pr=E9sentation de Firebird qui
>>permette =E0 la fois de voir de fa=E7on synth=E9tique ce qui distingue
>>Firebird des autres produits de sa cat=E9gorie (en terme de
>>fonctionnalit=E9s techniques notamment), le type de licence qu'il
>>utilise, les chiffres qui pr=E9sentent sa place sur le march=E9, les
>>principales entreprises ou administrations qui ont choisi de
>>travailler avec Firebird, l'avenir de Firebird....
>=20
vous pouvez aussi consulter :
<http://firebird.sourceforge.net/guide/FBFactsheet.html>

ce document n'est pas encore traduit en fran=E7ais par contre.

--=20
Philippe Makowski

Firebird serveur SQL open-source en fran=E7ais http://firebird-fr.eu.org

Ma cl=E9 PGP : http://makowski.eu.org/pgpkey.html

[Firebird-fr-support] Re: Documentation Firebird

[Philippe M. <mak...@fi...>]

Bonjour,
> J'aurai voulu savoir si vous aviez une pr=E9sentation de Firebird qui
> permette =E0 la fois de voir de fa=E7on synth=E9tique ce qui distingue
> Firebird des autres produits de sa cat=E9gorie (en terme de
> fonctionnalit=E9s techniques notamment), le type de licence qu'il
> utilise, les chiffres qui pr=E9sentent sa place sur le march=E9, les
> principales entreprises ou administrations qui ont choisi de
> travailler avec Firebird, l'avenir de Firebird....
je n'ai pas sous la main ce type de document, mais je vais essayer de
vous donner quelques pistes

   1. Firebird est tr=E8s facile =E0 installer et sa devise est : "instal=
lez
le et oubliez le !" Et c'est vrai. De plus Firebird prend peu de place
m=E9moire.
   2. Firebird a tous les outils qu'il faut pour pouvoir s'y connecter,
OLE, ODBC, JDBC, .Net, PHP, Perl, C, Delphi ....
   3. Une base Firebird peut aussi bien fonctionner sous Windows que
sous Linux ou un autre Unix
   4. Firebird a une gestion multig=E9n=E9rationnelle des enregistrements=
,
ce qui fait que jamais un utilisateur ne sera bloqu=E9 pour faire une mis=
e
=E0 jour d'un enregistrement parce qu'un autre fait une grosse requ=EAte
pour faire un =E9tat par exemple. C'est cette particularit=E9 qui a fait =
que
SAS =E0 choisit Firebird pour commander le projet Vulcan qui va servir =E0
developper la version 3.0 de Firebird (cf
http://firebirdnews.blogspot.com/2005/01/sas-is-company-that-comissioned-=
vulcan.html)

   5. Firebird est mature, les premi=E8res lignes de code qui lui ont
donn=E9 naissance ont =E9t=E9 =E9crites il y a 20 ans.
   6. Firebird est open-source ce qui est un gage de p=E9r=E9nit=E9 et de
s=E9curit=E9. Firebird est gratuit, pas de mise =E0 jour couteuses !
   7. Le projet open-source Firebird est bien structur=E9 avec la pr=E9se=
nce
dans les diff=E9rents niveau du projet de gens qui connaissent le produit
depuis sa naissance, des chefs de projets bien identifi=E9s, une fondatio=
n
qui g=E8re l'avenir de Firebird et les ressources qui lui sont allou=E9es=
.
   8. Firebird permet de fonctionner en mode autonome, c'est =E0 dire que
l'on peut tr=E8s facilement installer l'application et la base sur un
portable pour aller faire des d=E9monstrations ou des pr=E9sentations et
cela sans licence suppl=E9mentaire et sans installation fastidieuse.
   9. Firebird le SGBD open source pr=E9f=E9r=E9 des entreprises. Firebir=
d est
clairement le moteur de bases de donn=E9es pr=E9f=E9r=E9 parmis les moteu=
rs de
bases de donn=E9es Open-source pour un usage en entreprise, selon l=92=E9=
tude
faite aupr=E8s de 4000 professionnels par l=92organisme Evans. (cf :
http://www.evansdata.com/n2/pr/releases/EDCDB05_01.shtml)
  10. Firebird ne d=E9pend d'aucune structure commerciale, c'est une
Fondation =E0 but non lucratif qui d=E9cide de l'avenir de Firebird, les
d=E9cisions de developpement sont donc prisent en toute transparence.
  11. La licence de Firebird est la Initial Developer's PUBLIC LICENSE
Version 1.0 (un d=E9riv=E9 de la Mozilla Public License) qui est une lice=
nse
aggr=E9e par l'OSI mais qui permet un deploiement commercial du produit y
compris avec des produits non open-source (cf
http://www.firebirdsql.org/index.php?op=3Ddoc&id=3Didpl).
  12. Et peut =EAtre plus important, la communaut=E9 Firebird se porte bi=
en
et la communaut=E9 en langue fran=E7aise se structure petit =E0 petit.
  13. Des offres de service et support autour de Firebird existent.

sinon je vous invite =E0 visiter le site de Firebird
(http://www.firebirdsql.org) , celui d'Ibphoenix
(http://www.ibphoenix.com/) et celui de la Fondation
(http://firebird.sourceforge.net/index.php?op=3Dffoundation)

On pourrait indiquer encore beaucoup de choses, comme les limites
connues, le fait que Firebird g=E8re bien =E9videmment les transactions,
triggers,proc=E9dures stock=E9es, que pour ma part j'ai install=E9 Firebi=
rd
dans plus de 30 collectivit=E9s locales en France ...

En fait tout d=E9pend aussi de vos besoins, mais sachez que je suis tout
dispos=E9 =E0 vous donner plus d'informations sur tel ou tel point ou vou=
s
indiquer quelle personne en particulier contacter sur tel ou tel point
pr=E9cis.



--=20
Philippe Makowski

Firebird serveur SQL open-source en fran=E7ais http://firebird-fr.eu.org

Ma cl=E9 PGP : http://makowski.eu.org/pgpkey.html