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 !