Firebird et .net

[jose.ignacio.agata]

bonjour à tous

nous venons de développer quelques appli sous .net au lieu de Delphi et nous rencontrons une tonne de problèmes de stabilité de firebird. On ne sait pas si il y a un rapport entre .net et ces pb mais notre moteur firebird 1.5.3 tient apparemment pas la charge. Et s'arrête tout seul - sous linux opensuse superserveur - seul un kill -9 peut en venir à bout. On a l'impression d'une grosse perte de mémoire... car il pète même sans charge importante.

Concernant .net, nous gérons des pools de connexion à FB.

Un avis ou une idée sur l'origine du problème ?

D'avance merci.

[_skip]

Vous employez le provider ADO.net?
Vous utilisez des datareaders? Etes-vous sûr de bien appeler les fonctions dispose()?

Vous est-il possible de faire un test avec la 2.03?

[jose.ignacio.agata]

on est sur 1.53 et 2.0.3
Firebird .Net Data Provider Version 2.0.1 for .NET 2.0
pas de datareader et on utilise bien le dispose()

[makowski]

Le dispose() ne suffit pas
le dispose() ne fait que mettre les choses à la poubelle mais ne vide pas la poubelle, il faut faire un GC.collect()
Ensuite il faut voir comment son gérées les connexions et leur libération
avec .net on peut aller vite dans le mur sur la gestion de la mémoire.
Je ne suis pas un spécialiste de .Net mais je sais qu'on peut très vite avec aller dans des fuites de mémoires importantes.
Mais clairement, c'est un problème .Net

[_skip]

Le dispose() ne suffit pas
le dispose() ne fait que mettre les choses à la poubelle mais ne vide pas la poubelle, il faut faire un GC.collect()

Non c'est pas possible, les cas ou appeler soi-même le garbage collector est justifié sont très très rares. Surtout que dans cet exemple c'est le serveur qui crash, pas l'application cliente.
J'ai une application multi-site développée en .Net sur firebird, c'est impeccable niveau stabilité, la seule chose c'est que mon FB tourne sous du windows.

avec .net on peut aller vite dans le mur sur la gestion de la mémoire.
Je ne suis pas un spécialiste de .Net mais je sais qu'on peut très vite avec aller dans des fuites de mémoires importantes.

C'est absolument faux, le seul moyen d'avoir des fuites de mémoires c'est d'avoir des "strong references" sur des objets dont on a perdu la trace (ce qui n'arrive quasiment qu'avec les event handler lorsqu'ils sont mal gérés ou mal compris).

[makowski]

pour .net, c'est possible que tu es raison, je ne suis pas spécialiste et effectivement le dispose() doit pouvoir suffire, quand au crash coté serveur, sous 1.5 je connais quelques cas possibles mais résolus en 2.O
après sans connaitre les traitements demandés, il est impossible de répondre

[_skip]

Il faudrait qu'il puisse monitorer la taille du pool de connexion dans son application .Net. Afin de s'assurer qu'elles sont correctement recyclées.