Discussion :

[Pol63]

dans le finalize il reste possible d'appeler une méthode statiques quelque part qui s'occupera de faire ton traitement, ou au moins de se noter quelque part que ca doit etre fait et de rendre la main au finalize directement

[smyley]

J'aime pas trop passer par du statique pour gérer des action sur une classe mais ça marche parfois en effet
Par contre, il ne faut pas oublier que dans ce cas on passe par défaut dans un contexte multithreadé et il ne faut pas oublier d'utiliser des lock() pour éviter les problèmes.

[Sergejack]

Et si je vire le finalize pour ne laisser alors que le Dispose, celui-ci sera-t'il appellé par le GC ?

[tomlev]

Et si je vire le finalize pour ne laisser alors que le Dispose, celui-ci sera-t'il appellé par le GC ?

non
il faut l'appeler toi même

[Sergejack]

Ok.

Donc quand un objet est lié à des données en DB qui devraient disparaître à la mort de l'objet, il est impossible par ces principe de garantir que cela sera le cas si par exemple, le CLR est remplacé ou l'application fermée.

Finallement on ne peut rien faire dans ces deux cas où finalize est appellé sur l'ensemble des objets en mémoire (vu que rien n'est alors utilisable pour opérer sur la DB) ?

[smyley]

C'est pour ça que j'ai horreur du GC
Quand on veux programmer une véritable action à la mort d'un objet, on est obligé d'employer des tricks mais le refcount ça marche assez bien.

[tomlev]

C'est pour ça que j'ai horreur du GC
Quand on veux programmer une véritable action à la mort d'un objet, on est obligé d'employer des tricks mais le refcount ça marche assez bien.

A mon avis, c'est pas une bonne idée de se baser sur la "mort" d'un objet pour effectuer une action...

Dans le cas de Sergejack, je pense que la meilleure solution serait de mettre le code de nettoyage dans le Session_End du Global.asax

[smyley]

A mon avis, c'est pas une bonne idée de se baser sur la "mort" d'un objet pour effectuer une action...

C'est sur que c'est normalement une très mauvaise idée mais il y a des fois où l'on ne peut pas vraiment faire autrement ...

[Sergejack]

A mon avis, c'est pas une bonne idée de se baser sur la "mort" d'un objet pour effectuer une action...

Dans le cas de Sergejack, je pense que la meilleure solution serait de mettre le code de nettoyage dans le Session_End du Global.asax

J'y ai songé, mais il resterait le problème de l'impossibilité de faire du nettoyage à l'arrêt du site (site stoppé ou dll remplacées).

Et comme je le disais, refcount ou quoi que ce soit, à l'arrêt du site, les jeux sont faits, rien ne va plus.


Mon nettoyage DB, je vais devoir le faire ailleurs en fonction de paramètres décisionnels "est-ce que ceci semble devoir être supprimé ?".

Merci pour les éclaircissements.

[Pol63]

les tables # sont supprimés à la fermeture de la connexion qui les a créés ... si ca peut aider ...

enfin voir si y a pas moyen de gérer ca dans le sgbd directement

[tomlev]

J'y ai songé, mais il resterait le problème de l'impossibilité de faire du nettoyage à l'arrêt du site (site stoppé ou dll remplacées).

Et comme je le disais, refcount ou quoi que ce soit, à l'arrêt du site, les jeux sont faits, rien ne va plus.

Justement, j'en suis pas si sûr... tu as fait des tests ? à mon avis les évènements d'arrêt de l'application sont quand même exécutés avant que l'appli ne soit déchargée et redémarrée. Donc avec un peu de chance, le Session_End aussi...

[tomlev]

Justement, j'en suis pas si sûr... tu as fait des tests ? à mon avis les évènements d'arrêt de l'application sont quand même exécutés avant que l'appli ne soit déchargée et redémarrée. Donc avec un peu de chance, le Session_End aussi...

Bon, ben j'ai rien dit... IIS est moins malin que je pensais
J'ai fait le test, même le Application_End n'est pas exécuté. C'est un peu crade je trouve