Thread: [Firebird-fr-support] [Fwd: Re: Interbase, Firebird et transactions [long...]]
Brought to you by:
makowski
Menu
▾
▴
firebird-fr-support
|
From: Philippe M. <mak...@fi...> - 2005-04-13 11:35:00
|
[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 |
|
From: <be...@en...> - 2005-04-13 12:42:43
|
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 ! |
|
From: Philippe M. <mak...@fi...> - 2005-04-13 13:14:12
|
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 |
|
From: <be...@en...> - 2005-04-15 12:25:49
|
----- 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. |
|
From: Pierre Y. <zed...@ne...> - 2005-04-13 21:58:15
|
> 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 |
|
From: <be...@en...> - 2005-04-14 12:20:08
|
"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 |
|
From: Philippe M. <mak...@fi...> - 2005-04-15 13:41:44
|
Le 14/04/2005 14:19, B=E9renger Enselme a dit : > "Au niveau SNAPSHOT on choppe une exception. " >=20 > Absolument. Heu, m=EAme si on est en wait ? >=20 Oui, m=EAme en wait sauf si la premi=E8re transaction fait un Rollback mais il y a un truc que je ne comprend pas bien dans cette histoire de : >"Gestion "consistante" de l'acc=E8s concurrent : si deux threads =E9criv= ent > une m=EAme valeur au m=EAme endroit : > > updates comptes set > solde =3D solde + 2 > where client=3D'PIERRE'; > d'apr=E8s toi Pierre quel est le bon r=E9sultat final attendu ? que solde =3D solde +4 ? ou que solde =3D solde +2 ? si c'est solde +2 alors effectivement pas de pb, il y a un exception avec SNAPSHOT et tant mieux --=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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X