Discussion :

[PocoYote]

Bonjour,

J'ai un soucis avec Firebird. Et je ne sais pas comment le gérer. Il y a probablement une solution mais...
J'utilise Firebird 2.5 sous Windows avec la librairie Ibpp

- Connection à une base de données distante
- BEGIN TRANSACTION
- UPDATE CLIENTS SET TITLE='Test1' WHERE ID='1'
- UPDATE CLIENTS SET TITLE='Test2' WHERE ID='2'
- On débranche le câble réseau.

A partir de là, personne ne peut plus les modifier. Les clients avec ID 1 et 2 restent verrouillés.
Lorsqu'on tente de les modifier, le logiciel se fige... Le seul moyen de s'en sortir est de redémarrer le service Firebird sur le serveur.

Pourquoi Firebird n'est il pas capable de détecter que la connexion est perdue, et donc d'annuler automatiquement cette transaction au bout d'un certain temps...

[seabs]

Bonjour,

Amusant.

Pour un avion si tu arrêtes le moteur en vol, en général, il tombe et le moteur ne redémarre pas tout seul.

Alors pourquoi, tu veux débrancher le câble du serveur pendant le travail d'un ordinateur. Il y a une explication rationnel ou il s'agit d'une erreur.

Mon expérience est insuffisante pour répondre techniquement à ta question. Mais, tu as une solution c'est l'essentiel.

A+

[PocoYote]

Amusante également ta réponse.
J'ai simplement voulu simuler la panne constatée chez un client.

Un utilisateur, avec une connexion Wifi à priori de mauvaise qualité, s'est connecté à la base, et à verrouiller un enregistrement dans la base de données. Au début je pensais que ma BD était corrompue.
Mais en faisant des tests, j'ai vu que c'était juste un enregistrement qui "bloquait".
En redémarrant le service Firebird, tout est rentré dans l'ordre.

J'ai donc simplement essayer de simuler ce cas en débranchant un câble réseau (ce qui peut arrivé dans le monde réel : Wifi, switch éteint...)

Plusieurs problèmes :
1/ L'enregistrement reste verrouillé ad vitam aeternam
2/ Via Ibpp en tous cas, le logiciel se fige dès qu'un autre utilisateur veut modifier cet enregistrement. Aucune exception n'est remontée, il attend la fin de l'autre transaction. Il peut toujours attendre.
3/ Il faut forcement un administrateur pour redémarrer le service.

Je pense qu'il y a forcement une solution à ce problème. On dit que Firebird est auto administré. Il doit bien être possible de configurer un timeout sur une transaction sans activité...
Sinon, Firebird me parait bien fragile. Je ne piloterais pas un avion avec ce système à bord, ça c'est sûr.

[SergioMaster]

Bonjour,

Un utilisateur, avec une connexion Wifi à priori de mauvaise qualité, s'est connecté à la base, et à verrouiller un enregistrement dans la base de données.

j'ai également rencontrè ce problème, mais les enregistrements n'étaient pas bloqués grâce au mode de transaction, et je pense que c'est là que cela coince.
Donc quel est le mode utilisé ?

Dans mon cas, reste que l'utilisateur qui se déconnecte lui n'est pas averti, j'ai encore quelques difficultés sur ce point ! car :
- Windows est lent à réagir à la perte du wifi comme à le retrouver d'ailleurs , je n'ai pas trouvé de configuration pour ce point
- le réglage du time out de connexion à la base de données n'est pas facile (dans firebird.conf : 180 s par défaut c'est beaucoup ! mais sous les 10 s quand on a des postes en liaison via internet )

Je pense qu'il y a forcement une solution à ce problème.

oui, en changeant le mode de transaction dans le programme et en détruisant les transactions en Limbo de temps en temps (j'ai pris l'habitude d'avoir un backup de mes bases chaque jours, ou plutôt nuits, avant de faire ce dernier je fait un shutdown de la base puis après bien évidemment je redémarre cette dernière)
Avantage du backup (par Gback) ce dernier la nettoie.

Ceci étant, pas besoin de d'arrêter le service Firebird, un simple ShutDown/Restart de la base aurait fait l'affaire

[Artemus24]

Salut à tous.

En vous lisant, la première idée qui me vient à l'esprit est la connexion persistante.
Mettre un temps de connexion persistance plus courte si cette notion existe sous FireBird.
D'ailleurs, le problème disparaît lorsque vous avez redémarré le serveur FireBird.

@+

[Barbibulle]

Bonjour,

J'ai également des clients qui utilisent le wifi et j'ai aussi eut un qui était avec des câbles réseaux + prises murales installés par un plombier (enfin ça c'est ma supposition) toujours est il que de manière aléatoire la connexion disparaissait. Si c'était en plein traitement, effectivement la sentence était une application figée (même un retour de la connexion n'y faisait rien).
Obligé de kill le process.

Cependant je n'ai jamais eut d'enregistrements verrouillés comme vous le décrivez..

Une fois la connexion revenue, ils relançaient l'application et tout fonctionnait.

Alors je dirais comme SergiosMaster qu'il doit y avoir une mauvaise utilisation des transactions / paramétrage.

Firebird détecte normalement les transactions non validées / annulées. (suite à un crash ou problème de communication)

Ces transactions sont dites dans les limbes "In limbo". Avec gfix on peut lister ces transactions, on peut même les commit ou rollback.

Donc il faudrait nous en dire plus sur vos transactions, si vous avez changé le paramétrage serveur, le type d'installation classic/superserver ?

Pour terminer sur une note d'humour :

Sinon, Firebird me parait bien fragile. Je ne piloterais pas un avion avec ce système à bord, ça c'est sûr.

Je ferais de même, je ne monterai pas dans cet avion si c'est vous le pilote

[PocoYote]

Je ferais de même, je ne monterai pas dans cet avion si c'est vous le pilote

Bien joué.
Mais pour le coup dans ce cas, le pilote est un peu impuissant (enfin pour l'instant).

Merci à tous pour vos interventions constructives.
Je tiens à signaler qu'en 10 ans d'utilisation, c'est la 1ère fois que je détecte ce cas sur le logiciel en question. Bref, ça n'arrive pas tous les jours, et pourtant les utilisateurs ont parfois de mauvaises connexions, mais ce problème vendredi soir m'a un peu fait paniquer. Ce qui confirme que je ne suis pas si mauvais pilote et que Firebird reste fiable la majorité du temps.

Ce que je sais c'est que la connexion Wifi du client était vraiment mauvaise. Il a démarré une transaction, modifié un enregistrement puis n'a pas pu faire le commit. C'est confirmé pas son fichier de log. Ensuite l'enregistrement est resté bloqué jusqu'à le redémarrage du service Firebird. Je reproduis le problème à tous les coups avec le câble débranché avant le commit.

J'utilise Firebird en mode classic server sous Windows. Le fichier firebird.conf a été laissé pratiquement par défaut. J'ai juste augmenté légèrement la taille d'un cache.

j'ai également rencontrè ce problème, mais les enregistrements n'étaient pas bloqués grâce au mode de transaction, et je pense que c'est là que cela coince. Donc quel est le mode utilisé ?

Pour une transaction qui va écrire des données, j'utilise la transaction par défaut de Ibpp, c'est à dire :

Code :

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

Transaction TransactionFactory(Database db, TAM am = amWrite, TIL il = ilConcurrency, TLR lr = lrWait, TFF flags = TFF(0))

SergioMaster, quel mode de transaction utilises-tu ?
Est-il possible (je sais j'en demande bcp) que tu fasses un test rapide (débrancher le câble avant le commit). c'est très facile à reproduire.

oui, en changeant le mode de transaction dans le programme et en détruisant les transactions en Limbo de temps en temps (j'ai pris l'habitude d'avoir un backup de mes bases chaque jours, ou plutôt nuits, avant de faire ce dernier je fait un shutdown de la base puis après bien évidemment je redémarre cette dernière)
Avantage du backup (par Gback) ce dernier la nettoie.

Je fais des backups tous les jours également. Détruire les transactions, c'est intéressant (garbage collection, c'est ça ?). Je vais regarder si cela peut débloquer ce problème.

[TryExceptEnd]

Bonjour,

J'ai un soucis avec Firebird. Et je ne sais pas comment le gérer. Il y a probablement une solution mais...
J'utilise Firebird 2.5 sous Windows avec la librairie Ibpp

- Connection à une base de données distante
- BEGIN TRANSACTION
- UPDATE CLIENTS SET TITLE='Test1' WHERE ID='1'
- UPDATE CLIENTS SET TITLE='Test2' WHERE ID='2'
- On débranche le câble réseau.

A partir de là, personne ne peut plus les modifier. Les clients avec ID 1 et 2 restent verrouillés.
Lorsqu'on tente de les modifier, le logiciel se fige... Le seul moyen de s'en sortir est de redémarrer le service Firebird sur le serveur.

Pourquoi Firebird n'est il pas capable de détecter que la connexion est perdue, et donc d'annuler automatiquement cette transaction au bout d'un certain temps...

C'est clairement un DeadLock et sous Firebird donc des transactions mal gérées.
Si tu nous donnait les paramètres de tes transactions, on veras plus clair.

[PocoYote]

Pouvez-vous me dire ce que sont des transactions bien gérées ?
Avec une coupure réseau au milieu.

[SergioMaster]

Bonjour,

je ne connais pas très bien IBpp donc cela va être un peu dur mais je pense que cela vient de TIL il = ilConcurrency,moi je mettrai TIL il = ilReadCommitted, et TLR lr = lrnoWait pour tester

j'ai aussi eu un qui était avec des câbles réseaux + prises murales installés par un plombier

moi j'ai eu le cas d'un électricien qui m'a mis dans les murs un câble 8 fils gros comme le pouce
(bon c'était début des années 90 mais quand même ) essayez d'imaginer quand je suis venu avec ma pince et mes prises RJ45

un autre cas qui m'est arrivé, plus grave, mais avec les mêmes conséquences : le processeur du serveur en surchauffe : réponse, changement de serveur
et un autre moins ,des interférences sur le cablâge provenant de surtensions électriques provenant des machines outils : réponse , la fibre (le blindage n'était pas ce qu'il est maintenant)

SergioMaster, quel mode de transaction utilises-tu ?

généralement la plus simple possible

read_committed
no_rec_version
nowait

Est-il possible (je sais j'en demande bcp) que tu fasses un test rapide (débrancher le câble avant le commit). c'est très facile à reproduire.

tu en demandes beaucoup car je ne suis pas proche du serveur (en fait 330 km )
ceci dit, j'ai des utilisateurs encore plus éloignés (sous traitants en Tunisie, Inde) donc de nombreuses possibilités de perte de réseau et je n'ai jamais eu de problèmes de blocage

[TryExceptEnd]

Pouvez-vous me dire ce que sont des transactions bien gérées ?
Avec une coupure réseau au milieu.

La réponse était dans la question : quels sont les paramètres de tes transactions ?

[Barbibulle]

Alors, effectivement si on débranche le câble après une mise à jour, l'enregistrement est verrouillé et le reste.

La solution c'est de ne pas débrancher le câble !

Bon sinon tu ne peux pas t’empêcher de le débrancher il faut respecter quelques règles afin de minimiser le risque de verrouillage.

La plus importante, c'est de commit (ou commitRetaining) le plus rapidement après une mise à jour. Et si possible d'utiliser une transaction la plus courte possible (pour la mise à jour).
C'est pourquoi il est préconisé d'utiliser une transaction read pour l'affichage des données par exemple et une transaction séparée utilisée pour l'update/commit.

En théorie le risque existe encore mais c'est comme gagner au loto, ça fait 10 ans que je joue et je n'ai jamais gagné !

Dans ton cas la transaction n'est même pas dans les limbes, elle est active.

Une solution est effectivement un arrêter/redémarrer de FB ou encore un shutdown/online de la base avec gfix.
Cependant ces deux solutions ne font pas le ménage dans la liste des transactions...
Seul un backup/restore le fera. C'est donc cette dernière solution qu'il faut privilégier quand cela est possible.

Bref aucun avion n'est parfait mais il faut que le pilote fasse avec et c'est en connaissant bien l'avion qu'on minimise les problèmes.

Certaines librairie proposent même ce fonctionnement à double transaction une qui sera utilisée par les select et l'autre qui sera utilisée par chaque update/delete/insert. Je ne connais pas IBpp, peut être le propose t'il ?

NB : Attention la transaction de lecture si tu utilises Concurrency tu ne verras pas les mises à jours faites par la transaction update... il te faudra passer avec une transaction de type read_commited sinon il te faudra fermer complètement la transaction et la ré-ouvrir.

Dernière remarque tu peux lister les transactions actives et voir s'il y en a des vieilles avec la commande :

Code :

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

select * FROM MON$transactions

[PocoYote]

Bonjour,

Merci Barbibulle pour les infos.
Actuellement, je respecte déjà toutes ces règles et j'ai gagné au loto vendredi soir :
1/ Transactions les plus courtes et rapides possibles.
2/ Nouvelle transaction dès que j'ai besoin d'accéder aux données / d'écrire des données.
3/ Read + ReadCommitted + Wait pour les transactions en lecture seul
4/ ReadWrite + Concurrency (SNAPSHOT) + Wait pour les transactions en lecture/écriture.

Je pense changer 4/ en ReadCommitted. Ça ne résout pas mon problème, mais le fonctionnement me convient bien d'après mes tests. (En plus, c'est l'option par défaut dans SQL SERVER, ce qui me rassure).

J'ai testé ce matin, quel que soit le mode d'isolation, ça ne change rien, l'enregistrement est verrouillé, et il est impossible d'écrire dessus.
L'option NoWait va simplement déclencher directement une exception au lieu d'attendre la fin de l'autre transaction.
Et effectivement, le sweep ne fait rien car la transaction est encore active.
Chacun peut faire ce test très rapidement.

Mes transactions Firebird sont rapides, de l'ordre de quelques millièmes de seconde, mais avec une connexion mauvaise, ce temps augmente, et le commit peut très bien ne pas passer, la preuve cela m'est arrivé, sur une petite transaction en plus, no modifiant qu'un seul enregistrement. Un switch peut tomber, une connexion Wifi peut cracher...

Je trouve que le comportement actuel (transaction verrouillée alors que y'a plus de client) est la pire solution (dans mon cas).
J'avoue que ça n'arrive pratiquement jamais, mais ceci peut compromettre le fonctionnement d'une application (temps réel dans mon cas, heureusement ça ne pilote pas un avion sinon je ne dormirais plus). Je dois maintenant donner des explications au client, et je ne suis pas sûr que ça lui convienne / le rassure.
La solution serait d'avoir une option d'AutoRollback en cas de déconnexion du client.
Ou moins bien, d'avoir un timeout pour le rollback auto d'une transaction.
Ou peut être la proposition d'Artemus24, mais je n'ai pas vu une telle option.
Je ne sais pas si cela est possible.

Une autre solution serait de développer un logiciel local à la base de données, qui ferait interface avec le service Firebird, et ferait lui un Rollback automatiquement en cas de déconnexion avant le commit. Mais cela devrait être le boulot du service Firebird...

[Artemus24]

Salut Pocoyote.

Comment faites-vous le commit ?

J'ai l'impression que vous avez une étape précédente qui demande une validation, puis ensuite vous faites le commit.
C'est sûr que si votre câble est débranché juste avant la validation, la tâche sera bloquée.
D'où ma remarque sur la connexion persistante.

Avez-vous essayé de supprimer la tâche en question ?
Et que ce passe-t-il après ? Avez-vous accès à vos deux lignes ?

Car si la tâche est supprimée, normalement un rollback va se faire automatiquement.

@+

[Barbibulle]

Je trouve que le comportement actuel (transaction verrouillée alors que y'a plus de client) est la pire solution (dans mon cas).
J'avoue que ça n'arrive pratiquement jamais, mais ceci peut compromettre le fonctionnement d'une application (temps réel dans mon cas). Je dois maintenant donner des explications au client, et je ne suis pas sûr que ça lui convienne / le rassure.

J'utilise que des no_wait personnellement, la différence entre le wait et le no_wait c'est qu'en cas de conflit, par exemple une donnée est modifiée mais pas encore commit et une seconde transaction essaye de modifier également cette donnée. Si la seconde transaction est en no_wait on a immédiatement le message d'erreur. Si la deuxième transaction est en wait on a le message d'erreur, qu'une fois la première transaction commit. Etant donné que 99,9% de mes transactions se soldent par un commit, je ne vois pas l'utilité d'attendre...

Pour votre client, il faut lui faire comprendre que s''il travaille avec un wifi de mauvaise qualité il prend un risque...

Pour reprendre la métaphore du début, votre avion permet de voler dans un orage mais s'il se transforme en ouragan ce n'est pas garantie que vous vous en sortiez indemne...

[PocoYote]

@Artemus24 : Non j'ai simplement fait un logiciel de test qui attend effectivement un click sur un bouton pour faire le commit. Le logiciel en production fait le commit directement, immédiatement après les modifications.

@Barbibulle : je préfère le wait, car dans le cas du read committed, il ne va pas forcement déclencher une exception, mais pouvoir écrire quand l'autre transaction sera validée. Dans le cas d'un mode d'isolation Snaphsot, effectivement, il vaut mieux nowait.
Sinon je ne suis pas d'accord avec toi . Il devrait exister une option d'AutoRollback en cas de déconnexion du client (pas par défaut, mais ça devrait exister)...

[Artemus24]

Salut PocoYote.

Je ne pense pas que tu vas résoudre ton problème en changeant le paramétrage. Ton problème est plutôt applicatif.
J'insiste sur le fait qu'il y a une mise en attente quelque part, après avoir fait les update, et avant le commit.

Perdre la connexion a pour conséquence de ne plus pouvoir intervenir dans la tâche qui continue à s'exécuter.
Si tu demandes une validation, il va attendre ton intervention, et comme elle ne se fait pas, il reste bloqué.

Réduire le temps de la connexion persistante, ou bien tuer la tâche sont les seules solutions possibles.

@+

[PocoYote]

@Artemus24

Je comprends ta remarque mais ce n'est absolument pas ce qui se passe dans mon application. Je vous demande de me croire pour que l'on puisse avancer.

Je ne pense pas que tu vas résoudre ton problème en changeant le paramétrage. Ton problème est plutôt applicatif.
J'insiste sur le fait qu'il y a une mise en attente quelque part, après avoir fait les update, et avant le commit.

Il n'y a aucune mise en attente.

Perdre la connexion a pour conséquence de ne plus pouvoir intervenir dans la tâche qui continue à s'exécuter.

Oui

Si tu demandes une validation, il va attendre ton intervention, et comme elle ne se fait pas, il reste bloqué.

Je ne fais jamais une transaction avec une intervention de l'utilisateur au milieu.

Le problème a été mis en évidence, par les fichiers de log et des tests logiciels simples que tout le monde peut reproduire.... La perte de connexion n'est pas un phénomène si rare, donc je ne vois pas ce qui permet absolument de dire que le commit va arriver... C'est exactement ce qui est arrivé, et pourtant le commit est envoyé immédiatement après la(es) modification(s).

[Barbibulle]

je préfère le wait, car dans le cas du read committed, il ne va pas forcement déclencher une exception, mais pouvoir écrire quand l'autre transaction sera validée.

Je parle de modification par deux transactions différentes (pas de la lecture).

Le wait va faire que tu vas attendre que la transaction qui a modifié la donnée en premier soit TERMINEE.

ok mais si elle se termine par un COMMIT la transaction qui attendait se prend un exception deadlock conflict. Comme avec le parametre no_wait saut que t as attendu....(pour rien... enfin presque t as attendu dans l'espoir que l'autre fasse un rollback)
Si elle se termine pas un Rollback, là ok, il n'y a pas de vilain message, les modifications (de la transaction qui attendait) sont appliqués.

Mais si comme moi tu fais beaucoup plus de commit que de Rollback en cas de conflit, tu as plus de chance de faire attendre pour rien car l'issus sera la même (un deadlock).

Pour ce qui est de la lecture tu peux avoir un conflit lorsqu'une transaction read_committed + no_rec_version essaye de lire des données modifiées par une autre transaction non commit. Dans ce cas effectivement le wait peut éviter les messages d'exceptions. Mais j'y vois deux inconvénients d'une si tu as beaucoup de modifications tu risques un time-out, si tu as une transaction qui est resté active comme c'est le cas avec ton câble débranché tu ne pourra plus lire tes données...

C'est pourquoi je préfère le read_committed + rec_version qui renverra les dernières valeurs commit pour les transactions de lecture. (ou même la snapshot).


Pour revenir au "câble" de la discussion, en relisant des docs, je m’aperçois qu'il existe un paramètre dans les transactions qui pourra peut être vous aider autocommit !
Je ne l'ai jamais testé mais si je comprend bien chaque modification serait commit sans qu'on ait a le faire.

[PocoYote]

On est un peu hors sujet mais c'est intéressant.

Je parle de modification par deux transactions différentes (pas de la lecture).

Moi aussi, et donc je ne suis pas d'accord d'après les tests que j'ai fait ce matin.

ok mais si elle se termine par un COMMIT la transaction qui attendait se prend un exception deadlock conflict. Comme avec le parametre no_wait saut que t as attendu....(pour rien... enfin presque t as attendu dans l'espoir que l'autre fasse un rollback)

J'ai bien dit lorsque l'autre transaction sera validée (commit).
Et donc non la transaction qui a attendu en ReadCommitted ne va pas automatiquement déclencher un deadlock, même si elle modifie la même donnée.
J'imagine que le deadlock va se produire si par exemple TA modifie X, TB modifie Y, TA modifie Y (blocage en attente de TB), TB modifie X (deadlock).
Je peux me tromper, j'ai fait des tests rapidement. Je peux refaire le test, mais a priori je ne suis pas d'accord.

Pour revenir au "câble" de la discussion, en relisant des docs, je m’aperçois qu'il existe un paramètre dans les transactions qui pourra peut être vous aider autocommit !
Je ne l'ai jamais testé mais si je comprend bien chaque modification serait commit sans qu'on ait a le faire.

Merci de revenir à mon problème de perte de connexion et non de "câble".
Je ne veux surtout pas d'auto commit (ce pourrait être utile dans le cas particulier des transactions ne modifiant qu'un seul enregistrement, mais c'est rarement le cas dans une transaction pour conserver l'intégrité de la BD). C'est l'inverse, je voudrais par défaut un rollback dans ce cas.